TCP（傳輸層）

TCP報(bào)文段頭部

每個(gè) TCP 段都包含源端和目的端的端口號(hào)吨岭，用于尋找發(fā)送方和接收方應(yīng)用進(jìn)程叫搁。這兩個(gè)值加 上 IP 首部中的源端 IP 地址和目的端 IP 地址唯一確定一個(gè) TCP 連接。

首部固定部分各字段意義如下：

• 源端口和目的端口：各占 2 個(gè)字節(jié)，分別寫入源端口和目的端口在辆。IP 地址 + 端口號(hào)就可以確定一臺(tái)主機(jī)的一個(gè)進(jìn)程地址

• 序號(hào)/序列號(hào)（Sequense Number，SN）：在一個(gè) TCP 連接中傳送的字節(jié)流中的每一個(gè)字節(jié)都按順序編號(hào)度苔。該字段表示本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)匆篓。初始序號(hào)稱為 Init Sequense Number, ISN（專指TCP三次握手時(shí)前兩次握手的報(bào)文段中的序號(hào)）。

  例如寇窑，一報(bào)文段的序號(hào)是 101鸦概，共有 100 字節(jié)的數(shù)據(jù)。這就表明：本報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是 101甩骏，最后一個(gè)字節(jié)的序號(hào)是 200完残。顯然，下一個(gè)報(bào)文段的數(shù)據(jù)序號(hào)應(yīng)當(dāng)從 201 開始横漏，即下一個(gè)報(bào)文段的序號(hào)字段值應(yīng)為 201谨设。

• 確認(rèn)號(hào) ack：期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。若確認(rèn)號(hào)為 N缎浇，則表明：到序號(hào) N-1 為止的所有數(shù)據(jù)都已正確收到扎拣。

• 數(shù)據(jù)偏移（首部長(zhǎng)度）：它指出 TCP報(bào)文段的數(shù)據(jù)起始處距離 TCP報(bào)文段的起始處有多遠(yuǎn)。這個(gè)字段實(shí)際上是指出TCP報(bào)文段的首部長(zhǎng)度素跺。

• 保留：占 6 位二蓝，應(yīng)置為 0，保留為今后使用指厌。

6 個(gè)控制位非常重要：

• 緊急位 URG：當(dāng) URG = 1 時(shí)刊愚，表明此報(bào)文段中有緊急數(shù)據(jù)，是高優(yōu)先級(jí)的數(shù)據(jù)踩验，應(yīng)盡快發(fā)送鸥诽，不用在緩存中排隊(duì)商玫。該控制位需配合緊急指針使用。

  舉個(gè)例子：我們需要取消一個(gè)已經(jīng)發(fā)送了很長(zhǎng)程序的運(yùn)行牡借，因此用戶從鍵盤發(fā)出中斷命令拳昌。如果不使用緊急數(shù)據(jù)，那么這個(gè)指令將存儲(chǔ)在接收 TCP 的緩存末尾钠龙，只有在所有的數(shù)據(jù)被處理完畢后這兩個(gè)字符才被交付接收方的應(yīng)用進(jìn)程炬藤，這樣做就無(wú)法實(shí)現(xiàn)立即中斷。

• 確認(rèn) ACK：僅當(dāng) ACK = 1 時(shí)確認(rèn)號(hào)字段才有效碴里，當(dāng) ACK = 0 時(shí)確認(rèn)號(hào)無(wú)效沈矿。TCP 規(guī)定，在連接建立后所有傳送的報(bào)文段都必須把 ACK置為 1咬腋。

• 推送 PSH：接收方收到PSH = 1 的報(bào)文段细睡，就盡快地交付到上層應(yīng)用進(jìn)程。而不用等到整個(gè)緩存都填滿了后再向上交付帝火。當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行交互式的通信時(shí)溜徙，有時(shí)發(fā)送方的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能收到對(duì)方的響應(yīng)。在這種情況下犀填，發(fā)送方可以創(chuàng)建一個(gè)報(bào)文段并把 PSH 置為 1發(fā)送出去蠢壹。

• 復(fù)位 RST：當(dāng)RST = 1 時(shí)，表明 TCP連接中出現(xiàn)了嚴(yán)重錯(cuò)誤（如由于主機(jī)崩潰或其他原因）九巡，必須釋放連接图贸，然后再重新建立傳輸連接。

• 同步 SYN：SYN = 1 表示這是一個(gè)連接請(qǐng)求或連接確認(rèn)報(bào)文段冕广。當(dāng)SYN = 1 而 ACK = 0 時(shí)疏日，表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接撒汉，則應(yīng)在響應(yīng)的連接確認(rèn)報(bào)文段中使 SYN = 1 且 ACK = 1沟优。

• 終止 FIN：用來(lái)釋放一個(gè)連接。當(dāng)FIN = 1時(shí)，表明此報(bào)文段的發(fā)送方數(shù)據(jù)已發(fā)送完畢，并要求釋放TCP連接招狸。

• 窗口：用于流量控制忠聚，指明雙方的窗口大小巫击。

• 校驗(yàn)和：發(fā)送方初始校驗(yàn)和字段為0，對(duì)TCP 首部（包含12字節(jié)的偽首部）和 TCP 數(shù)據(jù)每個(gè) 16 bit進(jìn)行二進(jìn)制反碼的求和，然后重新填入校驗(yàn)和字段。接收方收到數(shù)據(jù)后以同樣的方式計(jì)算校驗(yàn)和隘谣，但接收方在計(jì)算過程中包含了發(fā)送方存在首部中的檢驗(yàn)和，因此啄巧，如果傳輸過程中沒有發(fā)生任何差錯(cuò)寻歧， 那么接收方計(jì)算的校驗(yàn)和結(jié)果應(yīng)該為全1掌栅。

  舉例：假設(shè)發(fā)送方計(jì)算的校驗(yàn)和為10101010。如果傳輸無(wú)誤熄求，那么接收方收到時(shí)渣玲，不包含校驗(yàn)和字段計(jì)算的反碼求和應(yīng)該為10101010逗概，再加上校驗(yàn)和字段的反碼（01010101）即為最終的校驗(yàn)和：11111111弟晚。

• 緊急指針：當(dāng) URG = 1 時(shí)，該字段才有效逾苫。關(guān)于緊急指針是指向緊急數(shù)據(jù)的最后一個(gè)字節(jié)還是指向緊急數(shù)據(jù)最后一個(gè)字節(jié)的下一個(gè)字節(jié)的爭(zhēng)論卿城。最初的TCP規(guī)范給出了兩種解釋，但Host Requirements RFC確定指向最后一個(gè)字節(jié)是正確的铅搓。然而瑟押，問題在于大多數(shù)的實(shí)現(xiàn)（包括源自伯克利的實(shí)現(xiàn)）繼續(xù)使用錯(cuò)誤的解釋。所有符合Host Requirements RFC的實(shí)現(xiàn)都是可兼容的星掰，但很有可能無(wú)法與其他大多數(shù)主機(jī)正確通信多望。

三次握手過程

三次握手（Three-way Handshake）指客戶端和服務(wù)器建立一個(gè)TCP連接時(shí)，雙方總共需要發(fā)送3個(gè)報(bào)文段氢烘。目的：確認(rèn)雙方的接收能力和發(fā)送能力是否正常怀偷；同時(shí)指定雙方的初始化序列號(hào)（ISN）為后面的可靠性傳送做準(zhǔn)備。

剛開始服務(wù)端處于監(jiān)聽狀態(tài)播玖，進(jìn)行三次握手由客戶端主動(dòng)發(fā)起：

1. 第一次握手：客戶端給服務(wù)端發(fā)一個(gè) 連接請(qǐng)求報(bào)文段椎工，頭部指明SYN=1，ACK=0以及初始化序列號(hào) ISN（seq=x）蜀踏。此報(bào)文段不能攜帶數(shù)據(jù)维蒙，但要消耗掉一個(gè)序號(hào)。隨后客戶端進(jìn)入 SYN_SENT （同步發(fā)送）狀態(tài)果覆。

2. 第二次握手：服務(wù)端收到客戶端的 連接請(qǐng)求報(bào)文段之后颅痊，向客戶端發(fā)送連接確認(rèn)報(bào)文段，頭部指明SYN=1局待，ACK=1八千，確認(rèn)號(hào)（ack）為x+1，并且也選擇一個(gè)初始化序列號(hào)y燎猛。隨后服務(wù)器進(jìn)入 SYN_RCVD （同步接收）的狀態(tài)恋捆。

3. 第三次握手：客戶端收到服務(wù)端的 連接確認(rèn)報(bào)文段之后，會(huì)向服務(wù)端回送一個(gè)確認(rèn)報(bào)文段重绷，頭部指明ACK=1沸停，確認(rèn)號(hào)ack=y+1，序號(hào)seq=x+1昭卓，該報(bào)文段可以攜帶數(shù)據(jù)愤钾，不攜帶數(shù)據(jù)則不消耗序號(hào)瘟滨。隨后客戶端進(jìn)入 ESTABLISHED （連接已建立）狀態(tài)。待服務(wù)器收到客戶端發(fā)送的 ACK 報(bào)文段也會(huì)進(jìn)入 ESTABLISHED 狀態(tài)能颁，完成三次握手杂瘸。

三次握手為什么不能是兩次？

1. 首先需要明確：三次握手是為了讓客戶端和服務(wù)端確認(rèn)對(duì)方的發(fā)送能力以及接受能力都是正常的伙菊。

   第一次握手：客戶端發(fā)送報(bào)文段败玉，服務(wù)端收到了。
   這樣服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力镜硕、服務(wù)端的接收能力是正常的运翼。

   第二次握手：服務(wù)端發(fā)送報(bào)文段，客戶端收到了兴枯。
   這樣客戶端就能得出結(jié)論：服務(wù)端的接收血淌、發(fā)送能力，客戶端的接收财剖、發(fā)送能力是正常的悠夯。不過此時(shí)服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常。

   第三次握手：客戶端發(fā)送報(bào)文段躺坟，服務(wù)端收到了沦补。
   這樣服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力正常瞳氓，服務(wù)器自己的發(fā)送策彤、接收能力也正常。

   因此匣摘，改成兩次握手店诗，服務(wù)端不能確定發(fā)送端的接收能力是否正常。

2. 且可能存在以下情況：客戶端向服務(wù)端發(fā)送 連接請(qǐng)求報(bào)文段音榜，但由于網(wǎng)絡(luò)原因滯留在網(wǎng)絡(luò)中庞瘸。客戶端超時(shí)重傳了一個(gè)新的連接請(qǐng)求報(bào)文段赠叼，利用新的請(qǐng)求客戶端和服務(wù)端成功建立連接并通信擦囊，通信完后關(guān)閉釋放了連接。但此時(shí)舊的（失效的）連接請(qǐng)求報(bào)文段重新到達(dá)服務(wù)端嘴办，如果采用兩次握手建立連接那么就會(huì)導(dǎo)致服務(wù)端建立錯(cuò)誤的連接瞬场。

3. 其次兩次握手，就建立連接涧郊，會(huì)放大 DDOS 攻擊贯被。

什么是半連接隊(duì)列

服務(wù)器第一次收到客戶端的連接請(qǐng)求報(bào)文段之后，就會(huì)處于SYN_RCVD(同步接收) 狀態(tài)，此時(shí)雙方還沒有完全建立其連接彤灶，服務(wù)器會(huì)把此種狀態(tài)下請(qǐng)求連接放在一個(gè)隊(duì)列里看幼，我們把這種隊(duì)列稱之為半連接隊(duì)列。

當(dāng)然還有一個(gè)全連接隊(duì)列幌陕，就是已經(jīng)完成三次握手诵姜，建立起連接的就會(huì)放在全連接隊(duì)列中。如果隊(duì)列滿了就有可能會(huì)出現(xiàn)丟包現(xiàn)象搏熄。

ISN(Initial Sequence Number)是固定的嗎棚唆？

TCP建立連接時(shí)會(huì)確定客戶端和服務(wù)端的ISN并交換，他們是后序所發(fā)送字節(jié)數(shù)據(jù)編號(hào)的原點(diǎn)搬卒。ISN是通過隨機(jī)生成算法生成的瑟俭，如果ISN是固定的翎卓，攻擊者很容易猜出后續(xù)的確認(rèn)號(hào)契邀，因此 ISN是動(dòng)態(tài)生成的。此外失暴，如果相同客戶端和服務(wù)端的前后兩次連接的ISN的相同坯门，第一次連接結(jié)束后，第二次連接數(shù)據(jù)傳輸過程中逗扒，屬于前一次連接但滯留在網(wǎng)絡(luò)中的報(bào)文段突然又到達(dá)服務(wù)端古戴，服務(wù)器是沒法區(qū)分的。

備注：RFC1948中提出了一個(gè)較好的初始化序列號(hào)ISN隨機(jī)生成算法矩肩。ISN = M + F(localhost, localport, remotehost, remoteport)现恼。M是一個(gè)計(jì)時(shí)器，這個(gè)計(jì)時(shí)器每隔4毫秒加1黍檩。F是一個(gè)Hash算法叉袍，根據(jù)源IP、目的IP刽酱、源端口喳逛、目的端口生成一個(gè)隨機(jī)數(shù)值。要保證hash算法不能被外部輕易推算得出棵里，用MD5算法是一個(gè)比較好的選擇润文。

三次握手過程中可以攜帶數(shù)據(jù)嗎？

第一次殿怜、第二次握手不可以攜帶數(shù)據(jù)典蝌，而第三次握手是可以攜帶數(shù)據(jù)的。

假如第一次握手可以攜帶數(shù)據(jù)的話头谜，如果有人要惡意攻擊服務(wù)器骏掀，那他每次都在第一次握手中的 連接請(qǐng)求報(bào)文段中放入大量的數(shù)據(jù)，并瘋狂重發(fā)。這會(huì)讓服務(wù)器花費(fèi)大量的內(nèi)存空間來(lái)緩存這些報(bào)文段砖织，這樣服務(wù)器就更容易被攻擊了款侵。

對(duì)于第三次握手，此時(shí)客戶端已經(jīng)處于連接狀態(tài)侧纯，他已經(jīng)知道服務(wù)器的接收新锈、發(fā)送能力是正常的了，所以可以攜帶數(shù)據(jù)是情理之中眶熬。

SYN攻擊是什么妹笆？

SYN攻擊是一種典型的DoS/DDoS(Distributed Denial of Service) 攻擊，攻擊方利用服務(wù)器端的資源是在二次握手時(shí)分配的這一特征進(jìn)行攻擊娜氏。SYN攻擊就是攻擊端在短時(shí)間內(nèi)偽造大量不存在的IP地址拳缠，并向服務(wù)端不斷地發(fā)送連接請(qǐng)求報(bào)文段，服務(wù)端則回復(fù)連接確認(rèn)報(bào)文段贸弥，并等待攻擊端的確認(rèn)報(bào)文段窟坐，由于源地址是偽造的，因此服務(wù)端需要不斷重發(fā)直至超時(shí)绵疲，這些偽造的連接請(qǐng)求報(bào)文段導(dǎo)致大量的請(qǐng)求連接長(zhǎng)時(shí)間占用半連接隊(duì)列哲鸳，導(dǎo)致正常的請(qǐng)求連接因?yàn)殛?duì)列滿而被丟棄，從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓盔憨。

第三次握手失敗怎么辦徙菠？

客戶端收到服務(wù)端的連接確認(rèn)報(bào)文段后，其狀態(tài)變?yōu)?code>ESTABLISHED郁岩，并會(huì)發(fā)送確認(rèn)報(bào)文段給服務(wù)端婿奔，準(zhǔn)備發(fā)送數(shù)據(jù)了。如果此時(shí)確認(rèn)報(bào)文段在網(wǎng)絡(luò)中丟失问慎，并且超時(shí)萍摊，那么服務(wù)端會(huì)重新發(fā)送連接確認(rèn)報(bào)文段。如果重傳指定次數(shù)之后仍然未收到客戶端的確認(rèn)報(bào)文段蝴乔，服務(wù)端將自動(dòng)關(guān)閉這個(gè)連接记餐。但是客戶端認(rèn)為這個(gè)連接已經(jīng)建立，如果客戶端向服務(wù)端發(fā)數(shù)據(jù)薇正，服務(wù)端將以復(fù)位報(bào)文段響應(yīng)片酝，客戶端方能感知到服務(wù)端的錯(cuò)誤。

四次揮手過程

四次揮手(Four-way handshake)指主動(dòng)方和和被動(dòng)方斷開 TCP連接需要發(fā)送四個(gè)包挖腰，客戶端或服務(wù)端均可主動(dòng)發(fā)起揮手動(dòng)作雕沿。

揮手前，雙方都處于ESTABLISHED 狀態(tài)猴仑，假如是客戶端先發(fā)起關(guān)閉請(qǐng)求审轮，對(duì)應(yīng)過程如下：

• 第一次揮手：客戶端向服務(wù)端發(fā)送一個(gè)連接釋放報(bào)文段肥哎，頭部指明FIN=1，序號(hào)seq=u疾渣。并停止發(fā)送數(shù)據(jù)篡诽，主動(dòng)關(guān)閉TCP連接。隨后客戶端進(jìn)入 FIN_WAIT1 （終止等待1）狀態(tài)榴捡，等待服務(wù)端的確認(rèn)杈女。
• 第二次揮手：服務(wù)端收到客戶端發(fā)來(lái)的連接釋放報(bào)文段后，回送 確認(rèn)報(bào)文段吊圾，頭部指明ACK=1达椰，確認(rèn)號(hào)ack=u+1，序號(hào)seq=v项乒，隨后服務(wù)端進(jìn)入 CLOSE_WAIT（關(guān)閉等待） 狀態(tài)啰劲。客戶端收到服務(wù)端的確認(rèn)報(bào)文段后檀何，進(jìn)入FIN_WAIT2（終止等待2）狀態(tài)蝇裤，等待服務(wù)端發(fā)出的連接釋放報(bào)文段。
• 第三次揮手：如果服務(wù)端也想斷開連接了埃碱，和客戶端的第一次揮手一樣猖辫，向客戶端發(fā)送連接釋放報(bào)文段酥泞，頭部指明FIN=1砚殿，ACK=1，序號(hào)seq=w芝囤，確認(rèn)號(hào)ack=u+1似炎，隨后服務(wù)端進(jìn)入LAST_ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)報(bào)文段悯姊。
• 第四次揮手：客戶端收到連接釋放報(bào)文段之后羡藐，同樣向服務(wù)端發(fā)出確認(rèn)報(bào)文段，頭部指明ACK=1悯许，seq=u+1仆嗦，ack=w+1，此時(shí)客戶端進(jìn)入 TIME_WAIT 狀態(tài)先壕。服務(wù)端收到客戶端的確認(rèn)報(bào)文段之后瘩扼，進(jìn)入 CLOSED 狀態(tài)±牛客戶端必須經(jīng)過 2*MSL 后才進(jìn)入 CLOSED 狀態(tài)集绰。此時(shí)TCP連接已經(jīng)完全釋放。

建立連接只需要握手三次谆棺，關(guān)閉連接時(shí)需要揮手四次呢栽燕？

其實(shí)在 TCP第二次握手的時(shí)候，服務(wù)端發(fā)送的 連接確認(rèn)報(bào)文段 將一個(gè) ACK 和一個(gè) SYN 合并到一起發(fā)送給服務(wù)端，所以減少了一次包的發(fā)送碍岔，三次便完成握手浴讯。對(duì)于四次揮手，因?yàn)?TCP是全雙工通信蔼啦，在主動(dòng)方發(fā)送連接釋放報(bào)文段后兰珍，被動(dòng)方可能還要發(fā)送數(shù)據(jù)，不能立即關(guān)閉被動(dòng)方到主動(dòng)方的數(shù)據(jù)通道询吴，所以被動(dòng)方不能將確認(rèn)報(bào)文段 與 連接釋放報(bào)文段合并回送給主動(dòng)方掠河。只能先發(fā)送將確認(rèn)報(bào)文段回送給主動(dòng)方，然后待被動(dòng)方無(wú)需發(fā)送數(shù)據(jù)時(shí)再回送 連接釋放報(bào)文段猛计，所以四次揮手必須使用四次數(shù)據(jù)包交互唠摹。

四次揮手時(shí)，主動(dòng)方等待2MSL的意義?

MSL是Maximum Segment Lifetime的英文縮寫奉瘤，指“報(bào)文段在網(wǎng)絡(luò)中最大生存時(shí)間”勾拉，超過這個(gè)時(shí)間報(bào)文段將被丟棄。

1. 保證主動(dòng)方發(fā)送的最后一個(gè)確認(rèn)報(bào)文段能夠到達(dá)被動(dòng)方盗温。

   這個(gè)確認(rèn)報(bào)文段有可能丟失藕赞，使得處于LAST-ACK（最后確認(rèn)）狀態(tài)的被動(dòng)方收不到該報(bào)文段，被動(dòng)方超時(shí)重傳連接釋放報(bào)文段卖局，而主動(dòng)方能在2MSL時(shí)間內(nèi)收到這個(gè)重傳的連接釋放報(bào)文段斧蜕，接著主動(dòng)方重傳一次確認(rèn)報(bào)文段，重啟2MSL計(jì)時(shí)器砚偶，最后雙方都進(jìn)入到CLOSED狀態(tài)批销。若主動(dòng)方發(fā)完確認(rèn)報(bào)文段后立即釋放連接，被動(dòng)方在超時(shí)未收到確認(rèn)報(bào)文段的情況就不能正常處理染坯，就導(dǎo)致被動(dòng)方無(wú)法正常進(jìn)入到CLOSED狀態(tài)均芽。

2. 防止“已失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。

   主動(dòng)方發(fā)送完最后一個(gè)確認(rèn)報(bào)文段单鹿，再經(jīng)過2MSL掀宋，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失，使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段仲锄。

其他

如果已經(jīng)建立了連接劲妙，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP設(shè)有一個(gè)敝绱埃活計(jì)時(shí)器是趴，服務(wù)器每收到一次客戶端的TCP報(bào)文段后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)澄惊∷敉荆客戶端如果出現(xiàn)故障若富雅，導(dǎo)致服務(wù)端兩小時(shí)都沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會(huì)每隔75秒鐘發(fā)送一個(gè)探測(cè)報(bào)文段肛搬，若一連發(fā)送10個(gè)探測(cè)報(bào)文段仍然沒反應(yīng)没佑，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接温赔。

TCP依靠哪些機(jī)制來(lái)保證可靠傳輸蛤奢？

1. 校驗(yàn)和：TCP通過校驗(yàn)和檢測(cè)數(shù)據(jù)在傳輸過程中是否發(fā)生改變，如果收到的報(bào)文段的校驗(yàn)和有差錯(cuò)陶贼，報(bào)文段將被丟棄啤贩。

2. 序列號(hào)和確認(rèn)應(yīng)答：TCP給發(fā)送的每一個(gè)報(bào)文段中都有序號(hào)字段，每次接收方收到數(shù)據(jù)后拜秧，都會(huì)對(duì)傳輸方進(jìn)行確認(rèn)應(yīng)答痹屹，即發(fā)送確認(rèn)報(bào)文段(ACK) ，其中的確認(rèn)號(hào)告訴發(fā)送方成功接收了哪些數(shù)據(jù)以及下一次的數(shù)據(jù)從哪里開始發(fā)枉氮。除此之外志衍，接收方可以根據(jù)序列號(hào)對(duì)數(shù)據(jù)包進(jìn)行排序，把有序數(shù)據(jù)傳送給應(yīng)用層聊替，并丟棄重復(fù)的數(shù)據(jù)楼肪。

3. 超時(shí)重傳：當(dāng) TCP 發(fā)出一個(gè)報(bào)文段后，它將啟動(dòng)一個(gè)定時(shí)器惹悄，等待接收端發(fā)回的確認(rèn)春叫。如果超過定時(shí)器超時(shí)還沒有收到確認(rèn)，發(fā)送方將重發(fā)這個(gè)報(bào)文段俘侠。

4. 約定最大報(bào)文段長(zhǎng)度(MSS)：在建立TCP連接的時(shí)候象缀，雙方約定最大報(bào)文段長(zhǎng)度作為發(fā)送的單位，理想的情況下是該長(zhǎng)度的數(shù)據(jù)剛好不被網(wǎng)絡(luò)層分片爷速。

5. 流量控制：TCP通過滑動(dòng)窗口機(jī)制實(shí)現(xiàn)流量控制，窗口（緩沖區(qū)）的大小就是發(fā)送方在無(wú)需等待確認(rèn)報(bào)文段的情況下還能發(fā)送的最大數(shù)據(jù)量臂寝。TCP通過窗口大小來(lái)協(xié)調(diào)端對(duì)端的發(fā)送速度备韧，確保接收端來(lái)得及接收揩局，從而盡可能減少丟包。

6. 擁塞控制：通過擁塞控制算法（慢開始廉沮、擁塞避免、快重傳徐矩、快恢復(fù)）滞时，根據(jù)全局網(wǎng)絡(luò)的擁塞程度來(lái)調(diào)整擁塞窗口的大小，改善網(wǎng)絡(luò)擁塞程度滤灯，從而盡可能減少丟包坪稽。

   備注：發(fā)送窗口的大小等于Min(接收窗口, 擁塞窗口)曼玩，因此是兩種流量控制和擁塞控制的共同作用。

ARQ協(xié)議與滑動(dòng)窗口機(jī)制的關(guān)系窒百？

自動(dòng)重傳請(qǐng)求 （ Automatic Repeat-reQuest 黍判， ARQ）是 OSI模型 中 數(shù)據(jù)鏈路層 和 傳輸層 的錯(cuò)誤糾正協(xié)議之一。其利用確認(rèn)和超時(shí)這兩個(gè)機(jī)制篙梢，可以在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸顷帖。ARQ協(xié)議分等停ARQ協(xié)議和連續(xù)ARQ協(xié)議，連續(xù)ARQ協(xié)議采用了滑動(dòng)窗口機(jī)制渤滞，后者又可分為后退N步協(xié)議和選擇重傳協(xié)議贬墩。

擁塞控制有哪些算法？

擁塞控制算法：慢開始妄呕、擁塞避免震糖、快重傳、快恢復(fù)趴腋。這些算法會(huì)根據(jù)網(wǎng)絡(luò)不同的擁塞狀況來(lái)搭配使用吊说。

慢開始算法：在一開始不清楚網(wǎng)絡(luò)擁塞程度時(shí)，避免一開始就向網(wǎng)絡(luò)中注入大量數(shù)據(jù)优炬，由小到大逐漸增大擁塞窗口數(shù)值颁井。cwnd（擁塞窗口） 初始值設(shè)為為 1，每經(jīng)過一個(gè)傳輸輪次（transmission round）蠢护，cwnd 加倍雅宾。(慢開始并不是指cwnd增長(zhǎng)慢)。當(dāng)擁塞窗口達(dá)到慢開始門限值 ssthresh葵硕，改用擁塞避免算法眉抬。(當(dāng)cwnd = ssthresh時(shí)，既可使用慢開始算法懈凹，也可使用擁塞避免算法)蜀变。

擁塞避免算法： 擁塞避免算法的思路是讓 cwnd緩慢地增大，即每經(jīng)過一個(gè)往返時(shí)間 RTT就把發(fā)送方的擁塞窗口 cwnd加1介评，而不是加倍库北。這樣，擁塞窗口 cwnd按線性規(guī)律緩慢增長(zhǎng)们陆，比慢開始算法的擁塞窗口增長(zhǎng)速率緩慢得多寒瓦。

無(wú)論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（計(jì)時(shí)器超時(shí)坪仇，未收到確認(rèn)）杂腰，就要把慢開始門限 ssthresh設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送窗口值的一半（但不能小于2）。然后把擁塞窗口 cwnd 重新設(shè)置為 1椅文，執(zhí)行慢開始算法喂很。

快重傳算法：快重傳算法要求接收方在收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)惜颇。發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期恤筛。(以便發(fā)送方及早知道丟失發(fā)生官还，及早進(jìn)行重傳)。與快重傳配合使用的還有快恢復(fù)算法毒坛。

image-20210717064453713

快恢復(fù)算法：當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)望伦，把 ssthresh門限減半〖逡螅考慮到如果網(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)屯伞，所以發(fā)送方認(rèn)為現(xiàn)在網(wǎng)絡(luò)可能沒有出現(xiàn)擁塞。所以此時(shí)不執(zhí)行慢開始算法豪直，而是將cwnd設(shè)置為ssthresh的大小劣摇，然后執(zhí)行擁塞避免算法。

image-20210717064707907

流量控制與擁塞控制有何不同弓乙？

流量控制：采用端對(duì)端的機(jī)制末融，接收端通過窗口字段告知發(fā)送端自己的接收能力，進(jìn)而協(xié)調(diào)發(fā)送端的發(fā)送速度暇韧，避免接收端來(lái)不及接收而丟包勾习。

擁塞控制：采用面向全局的機(jī)制，根據(jù)網(wǎng)絡(luò)的擁塞程度來(lái)改變擁塞窗口懈玻，進(jìn)而協(xié)調(diào)主機(jī)向網(wǎng)絡(luò)中注入數(shù)據(jù)的速度巧婶，改善網(wǎng)絡(luò)擁塞程度，從而盡可能減少丟包涂乌。

TCP 和 UDP 的區(qū)別艺栈？

TCP提供可靠服務(wù)，在傳送數(shù)據(jù)之前必須先建立連接历涝，數(shù)據(jù)傳送結(jié)束后要釋放連接诅需；UDP與之相反，只盡最大努力交付荧库。

TCP不提供廣播或多播服務(wù)；UDP則提供赵刑。

TCP是面向字節(jié)流的分衫；而UDP是面向報(bào)文段的。

TCP要提供可靠的服務(wù)般此，建立連接蚪战，釋放連接牵现，加之確認(rèn)、窗口邀桑、重傳瞎疼、流量控制、擁塞控制壁畸、定時(shí)器等機(jī)制都會(huì)占用更多的系統(tǒng)資源贼急，同時(shí)導(dǎo)致協(xié)議頭部增大（20 - 60 字節(jié)）；UDP則占用較少系統(tǒng)資源捏萍，協(xié)議頭部也更刑ァ（僅 8 字節(jié)）。

TCP提供可靠服務(wù)令杈，故使用在文件傳輸走敌、郵件傳輸?shù)葓?chǎng)景；雖然 UDP不提供可靠交付逗噩，但在某些情況下 UDP確是一種最有效的工作方式掉丽，如即時(shí)通訊，直播等場(chǎng)景异雁。

什么是 TCP 粘包問題捶障？

TCP粘包就是指發(fā)送方應(yīng)用層交給TCP發(fā)送的若干數(shù)據(jù)包經(jīng)過TCP傳輸?shù)竭_(dá)接收方時(shí)合并粘成了一個(gè)數(shù)據(jù)包，出現(xiàn)粘包的原因是多方面的片迅，可能是來(lái)自發(fā)送方残邀，也可能是來(lái)自接收方。

造成TCP粘包的原因柑蛇？

1. 發(fā)送方原因

   TCP默認(rèn)使用 Nagle算法芥挣，當(dāng)應(yīng)用層交付給TCP發(fā)送的數(shù)據(jù)包過于小時(shí)，發(fā)送方會(huì)收集了多個(gè)較小的數(shù)據(jù)包進(jìn)行合并發(fā)送耻台，這將會(huì)發(fā)生粘包空免。

2. 接收方原因

   TCP發(fā)送方發(fā)送數(shù)據(jù)很快，接收方TCP緩沖區(qū)收到大量數(shù)據(jù)盆耽，但應(yīng)用層取出數(shù)據(jù)的速度又太慢蹋砚，造成多個(gè)數(shù)據(jù)包被緩存，應(yīng)用層就有可能讀取到多個(gè)首尾相接粘到一起的數(shù)據(jù)包摄杂。

什么時(shí)候需要處理粘包問題坝咐？

1. 如果發(fā)送方發(fā)送的多個(gè)數(shù)據(jù)包本來(lái)就是同一塊數(shù)據(jù)的不同部分就不需要處理粘包現(xiàn)象。
2. 如果多個(gè)數(shù)據(jù)包毫不相干析恢，甚至是并列關(guān)系墨坚，那么這個(gè)時(shí)候就一定要處理粘包現(xiàn)象了。

如何處理粘包問題映挂？

在應(yīng)用層進(jìn)行處理泽篮。如：

1. 在應(yīng)用層交給TCP的每個(gè)數(shù)據(jù)包頭部都添加長(zhǎng)度字段盗尸，接收方應(yīng)用層讀取數(shù)據(jù)時(shí)根據(jù)數(shù)據(jù)包頭部長(zhǎng)度字段循環(huán)讀取相應(yīng)長(zhǎng)度的內(nèi)容；
2. 將應(yīng)用層交給TCP的每個(gè)數(shù)據(jù)包的首帽撑、尾分別添加開始符泼各、結(jié)束符。

HTTP（應(yīng)用層）

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬(wàn)維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議亏拉。HTTP是一個(gè)基于TCP/IP通信協(xié)議來(lái)傳遞數(shù)據(jù)（HTML扣蜻，圖片等文件，以及查詢結(jié)果等）专筷。

主要特點(diǎn)如下：

1. 簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)弱贼，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET磷蛹、HEAD吮旅、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同味咳。由于HTTP協(xié)議簡(jiǎn)單庇勃，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快槽驶。

2. 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象责嚷。正在傳輸?shù)念愋陀?code>Content-Type加以標(biāo)記。

3. 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求掂铐。服務(wù)器處理完客戶的請(qǐng)求罕拂，并收到客戶的應(yīng)答后，即斷開連接全陨。采用這種方式可以節(jié)省傳輸時(shí)間爆班。

4. 無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力辱姨。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息柿菩，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大雨涛。另一方面枢舶，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

5. 支持B/S及C/S模式

HTTP 協(xié)議由哪幾部分組成替久？

1. 請(qǐng)求協(xié)議信息由 4 部分組成：請(qǐng)求行凉泄、請(qǐng)求頭、空行蚯根、請(qǐng)求體

2. 響應(yīng)協(xié)議信息也由 4 部分組成：狀態(tài)行旧困、響應(yīng)頭、空行稼锅、響應(yīng)體

   使用curl命令查看協(xié)議詳情：

HTTP狀態(tài)碼吼具？

HTTP狀態(tài)碼由三個(gè)十進(jìn)制數(shù)字組成，第一個(gè)數(shù)字定義了狀態(tài)碼的類型矩距。HTTP 狀態(tài)碼共有 5 種類型：1xx, 2xx, 3xx, 4xx, 5xx拗盒。類型解釋以及部分常見狀態(tài)碼如下：

1. 1XX (Informational) : 接收的請(qǐng)求正在處理

   100 Continue ：表明請(qǐng)求到目前為止都處理的很正常，客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng)锥债。

2. 2XX (Success) : 請(qǐng)求正常處理完畢

   200 OK : 表示成功處理了請(qǐng)求陡蝇。

3. 3XX (Redirection) : 需要進(jìn)行附加操作以完成請(qǐng)求

   301 Moved Permanently ：永久性重定向。

   302 Found ：臨時(shí)性重定向哮肚。

4. 4XX (Client Error) : 服務(wù)器無(wú)法處理請(qǐng)求

   403 Forbidden ：請(qǐng)求被服務(wù)器拒絕登夫。

   404 Not Found : 服務(wù)器找不到請(qǐng)求的網(wǎng)頁(yè)。

5. 5XX (Server Error) : 服務(wù)器處理請(qǐng)求出錯(cuò)

   500 Internal Server Error ：服務(wù)器正在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤允趟。

更多：Http協(xié)議恼策、計(jì)算機(jī)網(wǎng)絡(luò) HTTP狀態(tài)碼和首部

狀態(tài)碼 301 和 302 的區(qū)別？

301和302狀態(tài)碼都表示重定向潮剪，就是說(shuō)瀏覽器在拿到服務(wù)器返回的這個(gè)狀態(tài)碼后會(huì)自動(dòng)跳轉(zhuǎn)到一個(gè)新的URL地址涣楷，這個(gè)地址可以從響應(yīng)頭部字段Location中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另一個(gè)地址B）

301: 表示永久重定向抗碰。該狀態(tài)碼表示請(qǐng)求的資源已被分配了新的 URI狮斗，以后應(yīng)使用資源現(xiàn)在所指的 URI。也就是說(shuō)弧蝇，如果已經(jīng)把資源對(duì)應(yīng)的 URI保存為書簽了碳褒，這時(shí)應(yīng)該按 Location字段提示的 URI重新保存。

302: 表示臨時(shí)重定向看疗。該狀態(tài)碼表示請(qǐng)求的資源已被分配了新的 URI沙峻，希望用戶（本次）能使用新的 URI訪問。和 301 狀態(tài)碼相似鹃觉，但 302狀態(tài)碼代表的資源不是被永久移動(dòng)专酗，只是臨時(shí)性質(zhì)的。換句話說(shuō)盗扇，已移動(dòng)的資源對(duì)應(yīng)的URI 將來(lái)還有可能發(fā)生改變祷肯。比如，用戶把 URI 保存成書簽疗隶，但不會(huì)像 301狀態(tài)碼出現(xiàn)時(shí)那樣去更新書簽佑笋，而是仍舊保留返回 302狀態(tài)碼的頁(yè)面對(duì)應(yīng)的 URI。

Forward和Redirect的區(qū)別斑鼻？

Forward：客戶端發(fā)出的請(qǐng)求被服務(wù)器內(nèi)部進(jìn)行轉(zhuǎn)發(fā)蒋纬，瀏覽器地址欄依然是之前的URL。就如 SpringMVC中，所有的請(qǐng)求都由 DispatcherServlet處理后再在服務(wù)器內(nèi)部進(jìn)行派發(fā)蜀备。

Redirect：實(shí)際是兩次HTTP請(qǐng)求关摇，服務(wù)器端在響應(yīng)第一次請(qǐng)求的時(shí)候，讓瀏覽器再向另外一個(gè)URL發(fā)出請(qǐng)求碾阁，從而達(dá)到轉(zhuǎn)發(fā)的目的输虱。

HTTP 請(qǐng)求方法了解哪些?

HTTP/1.0 定義了三種請(qǐng)求方法：GET, POST和 HEAD方法。

HTTP/1.1新增了：PUT食听、PATCH胸蛛、DELETE、CONNECT樱报、OPTIONS葬项、TRACE共5種HTTP請(qǐng)求方法。

備注：HTTP規(guī)范定義了以上方法的行為抖所，但實(shí)際開發(fā)中可以不遵守。例如：在GET請(qǐng)求對(duì)應(yīng)的接口中去更新資源痕囱，將會(huì)給自己帶來(lái)麻煩田轧。

HTTP冪等性了解嗎？

在編程領(lǐng)域鞍恢，對(duì)于同一個(gè)系統(tǒng)傻粘，在同樣條件下每窖，一次請(qǐng)求和重復(fù)多次請(qǐng)求對(duì)服端資源的影響是一致的，就稱該操作為冪等的弦悉。

HTTP常見冪等方法：GET窒典、PUT、DELETE警绩、

HTTP常見非冪等方法：POST崇败、PATCH

解釋：

PUT：第一次和第N次請(qǐng)求對(duì)服務(wù)端資源的影響是相同的，所以是冪等的肩祥。例如將id為1234的賬戶金額改為1000，多次調(diào)用對(duì)系統(tǒng)資源產(chǎn)生的影響是一致的缩膝。

DELETE：第一次和第N次請(qǐng)求對(duì)服務(wù)端資源的影響是相同的混狠，所以是冪等的。假如存在一個(gè)刪除 id為 1234的賬戶的接口疾层，第一次請(qǐng)求時(shí)會(huì)刪除将饺，而后面所有請(qǐng)求的時(shí)候由于系統(tǒng)中已經(jīng)沒有該資源了，所以第一次和后面的請(qǐng)求對(duì)服務(wù)端資源的影響（ id為 1234的資源不再存在）是相同的痛黎。

PATCH: URI對(duì)應(yīng)的資源不存在時(shí)服務(wù)端可以創(chuàng)建一個(gè)新資源予弧，因此兩次請(qǐng)求對(duì)服務(wù)端資源的影響可能會(huì)不同。并且服務(wù)端可以根據(jù)請(qǐng)求參數(shù)湖饱，動(dòng)態(tài)的計(jì)算出某個(gè)值掖蛤，例如每次請(qǐng)求后資源的某個(gè)參數(shù)減1，所以多次調(diào)用井厌，資源會(huì)有不同的變化蚓庭。綜上，PATCH方法是非冪等的仅仆。

了解REST風(fēng)格嗎器赞？

REST是一種架構(gòu)風(fēng)格，即Representational State Transfer的縮寫墓拜，譯為"表現(xiàn)層狀態(tài)轉(zhuǎn)化"港柜。REST的原則不僅僅適用于HTTP協(xié)議，但由于REST的應(yīng)用場(chǎng)景絕大部分是WEB應(yīng)用咳榜，故以下討論都基于HTTP夏醉。

資源是網(wǎng)絡(luò)上的一個(gè)實(shí)體，或者說(shuō)是網(wǎng)絡(luò)上的一個(gè)具體信息贿衍，一個(gè)資源可以被URI唯一標(biāo)識(shí)授舟。因此，表現(xiàn)層可以理解為資源的一種具體表現(xiàn)贸辈，如：文本文件释树、html文件等等肠槽。狀態(tài)轉(zhuǎn)化指客戶端和服務(wù)端的交互過程中通過HTTP協(xié)議提供的4個(gè)動(dòng)作（GET用來(lái)獲取資源，POST用來(lái)新建資源奢啥，PUT用來(lái)更新資源秸仙，DELETE用來(lái)刪除資源。）對(duì)服務(wù)器資源進(jìn)行操作桩盲，從而實(shí)現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"寂纪。

備注：而RESTful API就是符合REST風(fēng)格的API

GET 和 POST 的區(qū)別？

1. 從功能上講赌结，GET一般用來(lái)從服務(wù)器上獲取資源捞蛋，POST 一般用來(lái)在服務(wù)器上新增資源；
2. 從 REST服務(wù)角度上說(shuō)柬姚，GET是冪等的拟杉，而 POST不是冪等的;
3. 從請(qǐng)求參數(shù)形式上看，GET 請(qǐng)求的數(shù)據(jù)會(huì)附在 URL之后量承，POST請(qǐng)求會(huì)把提交的數(shù)據(jù)放置在是 HTTP請(qǐng)求報(bào)文的請(qǐng)求體中搬设；
4. 就安全性而言，POST的安全性要比 GET的安全性高撕捍，因?yàn)?GET 請(qǐng)求提交的數(shù)據(jù)將明文出現(xiàn)在 URL上拿穴，而且 POST請(qǐng)求參數(shù)則被包裝到請(qǐng)求體中凉驻，相對(duì)更安全止吐；
5. 從請(qǐng)求的大小看寂诱，GET請(qǐng)求的長(zhǎng)度受限于瀏覽器或服務(wù)器對(duì) URL長(zhǎng)度的限制忽你，允許發(fā)送的數(shù)據(jù)量比較小顷编，而 POST請(qǐng)求理論上是沒有大小限制驮捍。

怎么知道 HTTP 的報(bào)文長(zhǎng)度?

當(dāng)傳輸?shù)氖庆o態(tài)文件時(shí)它浅，服務(wù)端能夠很清楚的知道將要響應(yīng)內(nèi)容的大小拌消，可以通過響應(yīng)頭中的Content-Length 域來(lái)告訴客戶端報(bào)文的長(zhǎng)度蚤霞。如果服務(wù)端預(yù)先不知道將要響應(yīng)內(nèi)容的大行锸А（動(dòng)態(tài)生成的頁(yè)面）就需要在響應(yīng)頭中指明 Transfer-Encoding: chunked。表示響應(yīng)體是使用chunked分塊方式拼接成的昧绣，不需要Content-Length指明長(zhǎng)度规肴。每一個(gè)分塊包含十六進(jìn)制的長(zhǎng)度值和數(shù)據(jù)，最后一個(gè)分塊長(zhǎng)度值為0夜畴，表示實(shí)體結(jié)束拖刃，客戶端可以以此為標(biāo)志確認(rèn)數(shù)據(jù)已經(jīng)接收完畢。（這些是HTTP1.1的內(nèi)容贪绘，Content-Length字段不是必需的兑牡，因?yàn)闉g覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP連接，就表明收到的數(shù)據(jù)包已經(jīng)全了）税灌。

Keep-Alive（長(zhǎng)連接） 和 非 Keep-Alive 區(qū)別均函？

可以通過請(qǐng)求頭或響應(yīng)頭中的Connection域查看是否是Keep-Alive亿虽。

短連接：在HTTP/1.0中默認(rèn)使用短連接（也支持長(zhǎng)連接，得手動(dòng)設(shè)置Connection: keep-alive）苞也÷迕悖客戶端每個(gè)HTTP請(qǐng)求和響應(yīng)都會(huì)開啟和關(guān)閉一個(gè)單獨(dú)的TCP連接。

長(zhǎng)連接： 而從HTTP/1.1起如迟，默認(rèn)使用長(zhǎng)連接收毫。同一個(gè)客戶端和服務(wù)端之間的連續(xù)的多個(gè)HTTP請(qǐng)求和響應(yīng)可以通過一個(gè)TCP連接來(lái)完成。但是一個(gè)長(zhǎng)連接也不是一直保持殷勘，客戶端在最后一個(gè)請(qǐng)求時(shí)此再，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接劳吠，也可以通過 keep-alive timeout 參數(shù)來(lái)設(shè)置引润。

HTTP1.0、HTTP1.1痒玩、HTTP2的主要變化？

HTTP1.1變化：

長(zhǎng)連接：HTTP1.0默認(rèn)是短連接议慰，HTTP1.1 默認(rèn)支持長(zhǎng)連接蠢古，且引入了流水線技術(shù)（pipelining）。不僅多個(gè)請(qǐng)求可以復(fù)用同一個(gè)TCP連接别凹，并且同一個(gè)TCP連接里面草讶，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。這樣就進(jìn)一步改進(jìn)了HTTP協(xié)議的效率炉菲。（流水線方式會(huì)存在"隊(duì)頭阻塞"：如果第一個(gè)請(qǐng)求被阻塞堕战，即使后到的請(qǐng)求已經(jīng)處理完畢，響應(yīng)時(shí)依然要按請(qǐng)求的順序依次響應(yīng)）拍霜。

寬帶和網(wǎng)絡(luò)連接優(yōu)化：HTTP1.0 會(huì)存在一些性能浪費(fèi)嘱丢，每次請(qǐng)求都返回整個(gè)對(duì)象，即使只需要對(duì)象的一部分祠饺。HTTP1.1則可以通過設(shè)置range頭域越驻，僅請(qǐng)求返回資源的某一部分，也就是返回碼為206(Partial Content)的時(shí)候道偷，這對(duì)于性能優(yōu)化很有必要缀旁。

引入Host頭域：HTTP1.1添加了Host頭域，請(qǐng)求頭如果沒指定Host勺鸦，則返回404并巍。在HTTP1.0 中認(rèn)為每個(gè)IP地址都只屬于一臺(tái)服務(wù)器，因此换途，請(qǐng)求消息中的URL并沒有傳遞主機(jī)名懊渡。但隨著虛擬主機(jī)技術(shù)的發(fā)展刽射，在一臺(tái)物理主機(jī)上可以存在多個(gè)虛擬主機(jī)，并且它們共享一個(gè)IP地址距贷，僅靠IP地址無(wú)法區(qū)分請(qǐng)求的是哪個(gè)虛擬主機(jī)柄冲，故HTTP1.1加上了Host頭域來(lái)區(qū)分。

HTTP2 的變化：

二進(jìn)制：HTTP1.X （頭信息肯定是文本（ASCII編碼）忠蝗，數(shù)據(jù)體可以是文本现横，也可以是二進(jìn)制）的協(xié)議解析是基于文本格式，而HTTP2（頭信息和數(shù)據(jù)體都是二進(jìn)制阁最，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀）的協(xié)議解析是二進(jìn)制格式戒祠，解析更加高效。

多路復(fù)用(Mutiplexing) : 可以復(fù)用TCP連接速种，在一個(gè)連接里姜盈，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)配阵，這樣就避免了"隊(duì)頭堵塞"

header壓縮: HTTP1.X 協(xié)議不帶有狀態(tài)馏颂，每次請(qǐng)求都必須附上所有信息。所以棋傍，請(qǐng)求的很多字段都是重復(fù)的救拉，比如Cookie和User Agent，一模一樣的內(nèi)容瘫拣，每次請(qǐng)求都必須附帶亿絮，這會(huì)浪費(fèi)很多帶寬，也影響速度麸拄。HTTP2對(duì)這一點(diǎn)做了優(yōu)化派昧，引入了頭信息壓縮機(jī)制（header compression）。一方面拢切，頭信息使用gzip或compress壓縮后再發(fā)送蒂萎；另一方面，客戶端和服務(wù)器同時(shí)維護(hù)一張“首部表”來(lái)跟蹤和存儲(chǔ)之前發(fā)送的頭域（鍵-值對(duì)）失球，對(duì)于不變的域岖是，不再通過每次請(qǐng)求和響應(yīng)發(fā)送；通信期間幾乎不會(huì)改變的通用域鍵(User Agent实苞、Accept等等) 只需發(fā)送一次豺撑。

服務(wù)端推送(server push): 允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶端發(fā)送資源黔牵，這叫做服務(wù)器推送聪轿。常見場(chǎng)景是客戶端請(qǐng)求一個(gè)網(wǎng)頁(yè)，這個(gè)網(wǎng)頁(yè)里面包含很多靜態(tài)資源猾浦。正常情況下陆错，客戶端必須收到網(wǎng)頁(yè)后灯抛，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源音瓷，再發(fā)出靜態(tài)資源請(qǐng)求对嚼。其實(shí)，服務(wù)器可以預(yù)期到客戶端請(qǐng)求網(wǎng)頁(yè)后绳慎，很可能會(huì)再請(qǐng)求靜態(tài)資源纵竖，所以就主動(dòng)把這些靜態(tài)資源隨著網(wǎng)頁(yè)一起發(fā)給客戶端了。

HTTP 和 HTTPS 的主要區(qū)別杏愤？

端口：HTTP協(xié)議端口為80靡砌，HTTPS協(xié)議端口為443;

安全性：HTTP信息是明文傳輸；而HTTPS協(xié)議的信息是經(jīng)過SSL/TLS協(xié)議加密后傳輸?shù)纳郝ァ＃?TLS (Transport Layer Security通殃，傳輸層安全協(xié)議) 是 SSL (Secure Socket Layer，安全套接字層)的升級(jí)版）厕宗。

數(shù)字證書：HTTPS協(xié)議需要到CA (Certificate Authority)機(jī)構(gòu)申請(qǐng)數(shù)字證書画舌，絕大多數(shù)需要花錢申請(qǐng)。

響應(yīng)速度和資源消耗：HTTPS相比 HTTP在 TCP之上多了SSL/TLS 協(xié)議已慢，因此響應(yīng)速度會(huì)更慢骗炉，資源消耗會(huì)更多。

HTTPS 的工作過程蛇受？

前置：SSL/TLS中使用了非對(duì)稱加密，對(duì)稱加密以及HASH算法厕鹃。

對(duì)稱加密：加解密秘鑰一樣兢仰，優(yōu)點(diǎn)是加解密速度快，適合對(duì)大量數(shù)據(jù)加密剂碴；缺點(diǎn)是使用前需要傳輸給另一個(gè)使用方把将，容易泄露。

非對(duì)稱加密：分為私鑰和公鑰忆矛，私鑰自己保存無(wú)需發(fā)送察蹲，公鑰則是公開的，公鑰加密的信息只有私鑰能解密（反之亦然）催训。非對(duì)稱加密加解密速度慢洽议，只適合少量數(shù)據(jù)加密。

完整性校驗(yàn)算法（hash算法）：同一數(shù)據(jù)計(jì)算結(jié)果相同漫拭，一旦數(shù)據(jù)被修改結(jié)果就會(huì)改變亚兄。通常用來(lái)檢查數(shù)據(jù)是否被篡改。

個(gè)HTTPS請(qǐng)求實(shí)際上包含了兩次HTTP傳輸采驻，可以細(xì)分為 4 步：

1. 客戶端向服務(wù)器發(fā)起HTTPS請(qǐng)求审胚，連接到服務(wù)器的443端口匈勋。
2. 服務(wù)器將自己向 CA申請(qǐng)的數(shù)字證書發(fā)送給客戶端。數(shù)字證書包含了公鑰膳叨、簽名等信息洽洁。
3. 客戶端解析證書并對(duì)其進(jìn)行驗(yàn)證。如果證書不是可信機(jī)構(gòu)頒布菲嘴，或者證書中的域名與實(shí)際域名不一 致饿自，或者證書已經(jīng)過期，就會(huì)向訪問者顯示一個(gè)警告临谱，由其選擇是否還要繼續(xù)通信璃俗。 如果證書沒有問題，客戶端就會(huì)從服務(wù)器證書中取出服務(wù)器的公鑰悉默。然后客戶端還會(huì)生成一個(gè)隨機(jī)碼 KEY城豁，并使用公鑰將其加密。隨后客戶端把加密后的隨機(jī)碼 KEY發(fā)送給服務(wù)器抄课，作為后面對(duì)稱加密的密鑰唱星。
4. 服務(wù)器在收到消息后使用私鑰解密得到隨機(jī)碼 KEY，到此客戶端和服務(wù)器就已經(jīng)成功建立了安全連接跟磨。接下來(lái)就可以用對(duì)稱加密進(jìn)行通信了间聊。

Cookie是什么？

HTTP Cookie（也叫 Web Cookie或瀏覽器 Cookie）是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)抵拘，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)被攜帶并發(fā)送到服務(wù)器上哎榴。通常可以用于個(gè)性化設(shè)置僵蛛，瀏覽器行為跟蹤尚蝌。

Session是什么？

由于HTTP協(xié)議是無(wú)狀態(tài)的協(xié)議充尉，所以服務(wù)器需要記錄用戶狀態(tài)時(shí)就需要借助Session機(jī)制飘言。目前Session常見實(shí)現(xiàn)要借助Cookie，即服務(wù)器端創(chuàng)建一個(gè)Session對(duì)象驼侠，同時(shí)會(huì)創(chuàng)建一個(gè)特殊的Cookie對(duì)象（name為"JSESSIONID"姿鸿，value為Session對(duì)象的ID），然后將該Cookie對(duì)象發(fā)送至瀏覽器倒源。當(dāng)瀏覽器端發(fā)送第N（N>1）次請(qǐng)求到同一服務(wù)器時(shí)就會(huì)攜帶該name為JSESSIONID的Cookie對(duì)象苛预。服務(wù)器根據(jù)name為JSESSIONID的Cookie的value(sessionId)去查詢對(duì)應(yīng)Session對(duì)象，從而區(qū)分不同用戶相速。(Session對(duì)象默認(rèn)存活30分鐘)

Cookie和Session的區(qū)別碟渺？

1. 作用范圍不同，Cookie保存在客戶端（瀏覽器），Session保存在服務(wù)器端苫拍。
2. 存取方式的不同芜繁，Cookie只能保存 ASCII編碼的字符，Session可以存任意數(shù)據(jù)類型绒极，一般情況下我們可以在 Session 中保持一些常用變量信息骏令，比如說(shuō) 商品ID，商品數(shù)量（購(gòu)物車場(chǎng)景）等垄提。
3. 有效期不同榔袋，Cookie可設(shè)置為長(zhǎng)時(shí)間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能铡俐，Session一般失效時(shí)間較短凰兑，客戶端關(guān)閉或者 Session超時(shí)都會(huì)失效(Session對(duì)象默認(rèn)存活30分鐘)。
4. 隱私策略不同审丘，Cookie存儲(chǔ)在客戶端吏够，比較容易遭到不法獲取，早期有人將用戶的登錄名和密碼 存儲(chǔ)在 Cookie中導(dǎo)致信息被竊忍脖ā锅知；Session存儲(chǔ)在服務(wù)端，安全性相對(duì) Cookie要好一些脓钾。
5. 存儲(chǔ)大小不同售睹， 單個(gè) Cookie保存的數(shù)據(jù)量 <= 4KB；對(duì)于Session來(lái)說(shuō)并沒有上限可训，但出于對(duì)服務(wù)器端的性能考慮昌妹，Session內(nèi)不要存放過多的東西，并且應(yīng)設(shè)置Session刪除機(jī)制握截。

在瀏覽器中輸入 URL地址到顯示主頁(yè)的過程?

1. 首先根據(jù)URL進(jìn)行域名解析捺宗，得到對(duì)應(yīng)IP地址。解析時(shí)川蒙，首先查看瀏覽器DNS緩存是否命中，沒有的話再查看操作系統(tǒng)DNS緩存（hosts文件）是否命中长已，如果再?zèng)]有命中就會(huì)借助域名服務(wù)器進(jìn)行解析畜眨。
2. 位于應(yīng)用層瀏覽器的封裝好HTTP請(qǐng)求報(bào)文后交給應(yīng)用層的TCP協(xié)議。
3. TCP協(xié)議根據(jù)IP地址向服務(wù)器的80端口發(fā)起三次握手以建立TCP連接术瓮，隨后將HTTP報(bào)文作為自己的數(shù)據(jù)部分封裝到TCP報(bào)文段中發(fā)送出去康聂。
4. 服務(wù)器上的TCP協(xié)議收到TCP報(bào)文段后進(jìn)行拆包得到HTTP請(qǐng)求報(bào)文，HTTP請(qǐng)求報(bào)文隨后被應(yīng)用層的服務(wù)器程序讀取胞四、解析和處理后恬汁，按照之前類似步驟響應(yīng)數(shù)據(jù)給瀏覽器。
5. 瀏覽器得到HTTP響應(yīng)報(bào)文后進(jìn)行解析辜伟，渲染并顯示給用戶氓侧。

計(jì)算機(jī)分層模型

1. OSI 七層模型：大而全脊另，但是比較復(fù)雜、而且是先有了理論模型约巷，沒有實(shí)際應(yīng)用偎痛。
2. TCP/IP 四層模型：是由實(shí)際應(yīng)用發(fā)展總結(jié)出來(lái)的，從實(shí)質(zhì)上講独郎，TCP/IP只有最上面三層踩麦，最下面一 層沒有什么具體內(nèi)容，TCP/IP參考模型沒有真正描述這一層的實(shí)現(xiàn)氓癌。
3. 五層模型：五層模型只出現(xiàn)在計(jì)算機(jī)網(wǎng)絡(luò)教學(xué)過程中谓谦，這是對(duì)七層模型和四層模型的一個(gè)折中，既 簡(jiǎn)潔又能將概念闡述清楚贪婉。

三種模型以及對(duì)應(yīng)層次關(guān)系如下：

OSI七層網(wǎng)絡(luò)體系結(jié)構(gòu)各層的主要功能：

1. 應(yīng)用層：為應(yīng)用程序提供交互服務(wù)反粥。在互聯(lián)網(wǎng)中的應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS谓松，支持萬(wàn)維網(wǎng) 應(yīng)用的HTTP協(xié)議星压，支持電子郵件的SMTP協(xié)議等。

2. 表示層：主要負(fù)責(zé)數(shù)據(jù)格式的轉(zhuǎn)換鬼譬，如加密解密娜膘、轉(zhuǎn)換翻譯、壓縮解壓縮等优质。

3. 會(huì)話層：負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立竣贪、維持和終止通信，如服務(wù)器驗(yàn)證用戶登錄便是由會(huì)話層 完成的巩螃。

4. 運(yùn)輸層：有時(shí)也譯為傳輸層演怎，向主機(jī)進(jìn)程提供通用的數(shù)據(jù)傳輸服務(wù)。該層主要有以下兩種協(xié)議：

   • TCP：提供面向連接的避乏、可靠的數(shù)據(jù)傳輸服務(wù)爷耀；

   • UDP：提供無(wú)連接的、盡最大努力的數(shù)據(jù)傳輸服務(wù)拍皮，但不保證數(shù)據(jù)傳輸?shù)目煽啃浴?/p>

5. 網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點(diǎn)歹叮，確保數(shù)據(jù)及時(shí)傳送。主要包括IP協(xié)議铆帽。

6. 數(shù)據(jù)鏈路層：數(shù)據(jù)鏈路層通常簡(jiǎn)稱為鏈路層咆耿。將網(wǎng)絡(luò)層傳下來(lái)的IP數(shù)據(jù)包組裝成幀，并再相鄰節(jié)點(diǎn) 的鏈路上傳送幀爹橱。

7. 物理層 ：實(shí)現(xiàn)相鄰節(jié)點(diǎn)間比特流的透明傳輸萨螺，盡可能屏蔽傳輸介質(zhì)和通信手段的差異。