1. 網(wǎng)絡(luò)協(xié)議以及體系結(jié)構(gòu)

1.1 OSI體系結(jié)構(gòu)， TCP/IP體系結(jié)構(gòu)，5層體系結(jié)構(gòu)的對(duì)應(yīng)關(guān)系

五層協(xié)議只是OSI和TCP/IP的綜合，實(shí)際應(yīng)用還是TCP/IP的四層結(jié)構(gòu)烈炭。為了方便可以把下兩層稱(chēng)為網(wǎng)絡(luò)接口層缴罗。

image

OSI 7層

OSI七層參考模型的各個(gè)層次的劃分遵循下列原則：

• 同一層中的各網(wǎng)絡(luò)節(jié)點(diǎn)（理解為電腦）都有相同的層次結(jié)構(gòu)只厘，具有同樣的功能。

• 同一節(jié)點(diǎn)內(nèi)相鄰層之間通過(guò)接口(可以是邏輯接口)進(jìn)行通信舅巷。

• 七層結(jié)構(gòu)中的每一層使用下一層提供的服務(wù)羔味，并且向其上層提供服務(wù)。

• 不同節(jié)點(diǎn)的同等層按照協(xié)議實(shí)現(xiàn)對(duì)等層之間的通信钠右。

1. 物理層：規(guī)定通信設(shè)備的機(jī)械的赋元、電氣的、功能的和過(guò)程的特性飒房，用以建立搁凸、維護(hù)和拆除物理鏈路連接。具體地講狠毯，機(jī)械 特性規(guī)定了網(wǎng)絡(luò)連接時(shí)所需接插件的規(guī)格尺寸护糖、引腳數(shù)量和排列情況等;電氣特性規(guī)定了在物理連接上傳輸bit流時(shí)線路上信號(hào)電平的大小、阻抗匹配垃你、傳輸速率 距離限制等;功能特性是指對(duì)各個(gè)信號(hào)先分配確切的信號(hào)含義椅文，即定義了DTE和DCE之間各個(gè)線路的功能;規(guī)程特性定義了利用信號(hào)線進(jìn)行bit流傳輸?shù)囊唤M 操作規(guī)程，是指在物理連接的建立惜颇、維護(hù)皆刺、交換信息是，DTE和DCE雙放在各電路上的動(dòng)作系列凌摄。在這一層羡蛾，數(shù)據(jù)的單位稱(chēng)為比特(bit)。

2. 數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上锨亏，建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路痴怨，通過(guò)差錯(cuò)控制提供數(shù)據(jù)幀(Frame)在信道上無(wú)差錯(cuò)的傳輸，并進(jìn)行各電路上的動(dòng)作系列器予。數(shù)據(jù)鏈路層在不可靠的物理介質(zhì)上提供可靠的傳輸浪藻。該層的作用包括：物理地址尋址、數(shù)據(jù)的成幀乾翔、流量控制爱葵、數(shù)據(jù)的檢錯(cuò)、重發(fā)等反浓。在這一層萌丈，數(shù)據(jù)的單位稱(chēng)為幀(frame)。鏈路層規(guī)定了一個(gè)特性：（物理幀的大欣自颉）最大傳輸單元MTU：對(duì)數(shù)據(jù)幀長(zhǎng)度的一種限制辆雾，以太網(wǎng)和802.3對(duì)數(shù)據(jù)幀長(zhǎng)度限制的最大值分別是1500字節(jié)和1429字節(jié)。不同物理網(wǎng)絡(luò)技術(shù)的MTU不同月劈。

3. 網(wǎng)絡(luò)層：在 計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行通信的兩個(gè)計(jì)算機(jī)之間可能會(huì)經(jīng)過(guò)很多個(gè)數(shù)據(jù)鏈路度迂，也可能還要經(jīng)過(guò)很多通信子網(wǎng)藤乙。網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點(diǎn)， 確保數(shù)據(jù)及時(shí)傳送英岭。網(wǎng)絡(luò)層將數(shù)據(jù)鏈路層提供的幀組成數(shù)據(jù)包湾盒，包中封裝有網(wǎng)絡(luò)層報(bào)頭，其中含有邏輯地址信息——源站點(diǎn)和目的站點(diǎn)地址的網(wǎng)絡(luò)地址诅妹。如 果你在談?wù)撘粋€(gè)IP地址罚勾，那么你是在處理第3層的問(wèn)題，這是“數(shù)據(jù)包”問(wèn)題吭狡，而不是第2層的“幀”尖殃。IP是第3層問(wèn)題的一部分，此外還有一些路由協(xié)議和地 址解析協(xié)議(ARP)划煮。有關(guān)路由的一切事情都在這第3層處理送丰。地址解析和路由是3層的重要目的。網(wǎng)絡(luò)層還可以實(shí)現(xiàn)擁塞控制弛秋、網(wǎng)際互連等功能器躏。在這一層，數(shù)據(jù)的單位稱(chēng)為數(shù)據(jù)包(packet)蟹略。網(wǎng)絡(luò)層協(xié)議的代表包括：IP登失、IPX、RIP挖炬、OSPF等揽浙。

4. 傳輸層：第4層的數(shù)據(jù)單元也稱(chēng)作數(shù)據(jù)包(packets)。但是意敛，當(dāng)你談?wù)揟CP等具體的協(xié)議時(shí)又有特殊的叫法馅巷，TCP的數(shù)據(jù)單元稱(chēng)為段 (segments)而UDP協(xié)議的數(shù)據(jù)單元稱(chēng)為數(shù)據(jù)報(bào)(datagrams)。這個(gè)層負(fù)責(zé)獲取全部信息草姻，因此钓猬，它必須跟蹤數(shù)據(jù)單元碎片、亂序到達(dá)的 數(shù)據(jù)包和其它在傳輸過(guò)程中可能發(fā)生的危險(xiǎn)撩独。第4層為上層提供端到端(最終用戶到最終用戶)的透明的敞曹、可靠的數(shù)據(jù)傳輸服務(wù)。所謂透明的傳輸是指在通信過(guò)程中 傳輸層對(duì)上層屏蔽了通信傳輸系統(tǒng)的具體細(xì)節(jié)跌榔。傳輸層協(xié)議的代表包括：TCP、UDP等捶障。

5. 會(huì)話層：這一層也可以稱(chēng)為會(huì)晤層或?qū)υ拰由耄跁?huì)話層及以上的高層次中，數(shù)據(jù)傳送的單位不再另外命名项炼，而是統(tǒng)稱(chēng)為報(bào)文担平。會(huì)話層不參與具體的傳輸示绊，它提供包括訪問(wèn)驗(yàn)證和會(huì)話管理在內(nèi)的建立和維護(hù)應(yīng)用之間通信的機(jī)制。如服務(wù)器驗(yàn)證用戶登錄便是由會(huì)話層完成的暂论。

6. 表示層：這一層主要解決擁護(hù)信息的語(yǔ)法表示問(wèn)題面褐。它將欲交換的數(shù)據(jù)從適合于某一用戶的抽象語(yǔ)法，轉(zhuǎn)換為適合于OSI系統(tǒng)內(nèi)部使用的傳送語(yǔ)法取胎。即提供格式化的表示和轉(zhuǎn)換數(shù)據(jù)服務(wù)展哭。數(shù)據(jù)的壓縮和解壓縮， 加密和解密等工作都由表示層負(fù)責(zé)闻蛀。

7. 應(yīng)用層：應(yīng)用層為操作系統(tǒng)或網(wǎng)絡(luò)應(yīng)用程序提供訪問(wèn)網(wǎng)絡(luò)服務(wù)的接口匪傍。應(yīng)用層協(xié)議的代表包括：Telnet、FTP觉痛、HTTP等役衡。

1.2 網(wǎng)絡(luò)層次與數(shù)據(jù)傳遞

image

image

1.3 各層中的設(shè)備

OSI 七層模型通過(guò)七個(gè)層次化的結(jié)構(gòu)模型使不同的系統(tǒng)不同的網(wǎng)絡(luò)之間實(shí)現(xiàn)可靠的通訊，因此其最主要的功能就是幫助不同類(lèi)型的主機(jī)實(shí)現(xiàn)數(shù)據(jù)傳輸 薪棒。完成中繼功能的節(jié)點(diǎn)通常稱(chēng)為中繼系統(tǒng)手蝎。

一個(gè)設(shè)備工作在哪一層，關(guān)鍵看它工作時(shí)利用哪一層的數(shù)據(jù)頭部信息俐芯。網(wǎng)橋工作時(shí)棵介，是以MAC頭部來(lái)決定轉(zhuǎn)發(fā)端口的，因此顯然它是數(shù)據(jù)鏈路層的設(shè)備泼各。具體說(shuō):

• 物理層：網(wǎng)卡鞍时，網(wǎng)線，集線器扣蜻，中繼器逆巍，調(diào)制解調(diào)器

• 數(shù)據(jù)鏈路層：網(wǎng)橋，交換機(jī)

• 網(wǎng)絡(luò)層：路由器

• 網(wǎng)關(guān)工作在第四層傳輸層及其以上 　 集線器是物理層設(shè)備,采用廣播的形式來(lái)傳輸信息莽使。

交換機(jī)就是用來(lái)進(jìn)行報(bào)文交換的機(jī)器锐极。多為鏈路層設(shè)備(二層交換機(jī))，能夠進(jìn)行地址學(xué)習(xí)芳肌，采用存儲(chǔ)轉(zhuǎn)發(fā)的形式來(lái)交換報(bào)文灵再。

路由器的一個(gè)作用是連通不同的網(wǎng)絡(luò)，另一個(gè)作用是選擇信息傳送的線路亿笤。選擇通暢快捷的近路翎迁，能大大提高通信速度，減輕網(wǎng)絡(luò)系統(tǒng)通信負(fù)荷净薛，節(jié)約網(wǎng)絡(luò)系統(tǒng)資源汪榔，提高網(wǎng)絡(luò)系統(tǒng)暢通率。

1.4 各層中的協(xié)議

image

2. TCP/IP協(xié)議

2.1 IP

因?yàn)榫W(wǎng)絡(luò)層是整個(gè)互聯(lián)網(wǎng)的核心肃拜，因此應(yīng)當(dāng)讓網(wǎng)絡(luò)層盡可能簡(jiǎn)單痴腌。網(wǎng)絡(luò)層向上只提供簡(jiǎn)單靈活的雌团、無(wú)連接的、盡最大努力交互的數(shù)據(jù)報(bào)服務(wù)士聪。

使用 IP 協(xié)議锦援，可以把異構(gòu)的物理網(wǎng)絡(luò)連接起來(lái)，使得在網(wǎng)絡(luò)層看起來(lái)好像是一個(gè)統(tǒng)一的網(wǎng)絡(luò)剥悟。

ip的功能：

1. 路由尋址

2. 數(shù)據(jù)分片

2.1.1 IP數(shù)據(jù)報(bào)格式

image

版本 : 有 4（IPv4）和 6（IPv6）兩個(gè)值灵寺；

首部長(zhǎng)度 : 占 4 位，因此最大值為 15懦胞。因?yàn)楣潭ú糠珠L(zhǎng)度為 20 字節(jié)替久，因此該值最小為 5。如果可選字段的長(zhǎng)度不是 4 字節(jié)的整數(shù)倍躏尉，就用尾部的填充部分來(lái)填充蚯根。

區(qū)分服務(wù) : 用來(lái)獲得更好的服務(wù)，一般情況下不使用胀糜。

總長(zhǎng)度 : 包括首部長(zhǎng)度和數(shù)據(jù)部分長(zhǎng)度颅拦。

生存時(shí)間 ：TTL，它的存在是為了防止無(wú)法交付的數(shù)據(jù)報(bào)在互聯(lián)網(wǎng)中不斷兜圈子教藻。以路由器跳數(shù)為單位距帅，當(dāng) TTL 為 0 時(shí)就丟棄數(shù)據(jù)報(bào)。

協(xié)議 ：指出攜帶的數(shù)據(jù)應(yīng)該上交給哪個(gè)協(xié)議進(jìn)行處理括堤，例如 ICMP碌秸、TCP、UDP 等悄窃。

首部檢驗(yàn)和 ：因?yàn)閿?shù)據(jù)報(bào)每經(jīng)過(guò)一個(gè)路由器讥电，都要重新計(jì)算檢驗(yàn)和，因此檢驗(yàn)和不包含數(shù)據(jù)部分可以減少計(jì)算的工作量轧抗。

標(biāo)識(shí) : 在數(shù)據(jù)報(bào)長(zhǎng)度過(guò)長(zhǎng)從而發(fā)生分片的情況下恩敌，相同數(shù)據(jù)報(bào)的不同分片具有相同的標(biāo)識(shí)符。

片偏移 : 和標(biāo)識(shí)符一起横媚，用于發(fā)生分片的情況纠炮。片偏移的單位為 8 字節(jié)。

image

2.1.2 分片和重組

對(duì)數(shù)據(jù)報(bào)進(jìn)行分片的原因灯蝴？

片偏移的作用恢口？為什么需要片偏移？

在分組的傳輸通路上穷躁，分片操作只能出現(xiàn)在兩個(gè)MTU不同的網(wǎng)絡(luò)的交界處耕肩，也就是出現(xiàn)在路由器上;進(jìn)入一個(gè)新網(wǎng)絡(luò)時(shí)，若新網(wǎng)絡(luò)的MTU小于原有網(wǎng)絡(luò)的MTU，則可能需要進(jìn)行分片;若新MTU值不小于原有MTU就不必進(jìn)行分片看疗。

重組：重組是分片的逆過(guò)程。所有的重組操作都在目的主機(jī)上進(jìn)行睦授。

2.1.3 IPV6

我國(guó)在2014-2015年也逐步停止了向新用戶和應(yīng)用分配 IPv4 地址两芳。 解決 IP 地址耗盡的根本措施就是采用具有更大地址空間的新版本的 IP，即 IPv6去枷。

• 更大的地址空間怖辆。IPv6 將地址從 IPv4 的 32 位 增大到了 128 位。

• 擴(kuò)展的地址層次結(jié)構(gòu)删顶。

• 靈活的首部格式竖螃。 IPv6 定義了許多可選的擴(kuò)展首部。

• 改進(jìn)的選項(xiàng)逗余。 IPv6 允許數(shù)據(jù)報(bào)包含有選項(xiàng)的控制信息特咆，其選項(xiàng)放在有效載荷中。

• 允許協(xié)議繼續(xù)擴(kuò)充录粱。

• 支持即插即用（即自動(dòng)配置）腻格。因此 IPv6 不需要使用 DHCP。

• 支持資源的預(yù)分配啥繁。 IPv6 支持實(shí)時(shí)視像等要求菜职，保證一定的帶寬和時(shí)延的應(yīng)用。

• IPv6 首部改為 8 字節(jié)對(duì)齊旗闽。首部長(zhǎng)度必須是 8 字節(jié)的整數(shù)倍酬核。原來(lái)的 IPv4 首部是 4 字節(jié)對(duì)齊。

IPV6數(shù)據(jù)包格式：

image

V4向V6過(guò)渡：

向 IPv6 過(guò)渡只能采用逐步演進(jìn)的辦法适室，同時(shí)嫡意，還必須使新安裝的 IPv6 系統(tǒng)能夠向后兼容：IPv6 系統(tǒng)必須能夠接收和轉(zhuǎn)發(fā) IPv4 分組，并且能夠?yàn)?IPv4 分組選擇路由亭病。

由于IPv6本身不兼容IPv4鹅很，大規(guī)模部署IPv6還面臨不少挑戰(zhàn)。目前可行的辦法是使用過(guò)渡技術(shù)罪帖，將IPv4逐漸演進(jìn)到IPv6促煮，當(dāng)前主要有兩種主流的過(guò)渡技術(shù)

兩種向 IPv6 過(guò)渡的策略：

• 使用雙協(xié)議棧

• 使用隧道技術(shù)

雙協(xié)議棧：主機(jī)在和 IPv6 主機(jī)通信時(shí)是采用 IPv6 地址，而和 IPv4 主機(jī)通信時(shí)就采用 IPv4 地址整袁。 根據(jù) DNS 返回的地址類(lèi)型可以確定使用 IPv4 地址還是 IPv6 地址菠齿。要求所有的節(jié)點(diǎn)都支持雙協(xié)議棧

image

隧道技術(shù)：在 IPv6 數(shù)據(jù)報(bào)要進(jìn)入IPv4網(wǎng)絡(luò)時(shí)，把 IPv6 數(shù)據(jù)報(bào)封裝成為 IPv4 數(shù)據(jù)報(bào)坐昙，整個(gè)的 IPv6 數(shù)據(jù)報(bào)變成了 IPv4 數(shù)據(jù)報(bào)的數(shù)據(jù)部分绳匀。 當(dāng) IPv4 數(shù)據(jù)報(bào)離開(kāi) IPv4 網(wǎng)絡(luò)中的隧道時(shí)，再把數(shù)據(jù)部分（即原來(lái)的 IPv6 數(shù)據(jù)報(bào)）交給主機(jī)的 IPv6 協(xié)議棧。

image

IPV6的分片功能

IPv6禁止中間節(jié)點(diǎn)設(shè)備對(duì)IP報(bào)文進(jìn)行分片疾棵。事實(shí)上戈钢，IPv6不能完全放棄分片機(jī)制，只是說(shuō)它用一種完全不同的機(jī)制來(lái)實(shí)現(xiàn)分片：

• 分片只能在端到端進(jìn)行是尔！分片和重組只能在端主機(jī)進(jìn)行殉了。

• 分片信息不在IPv6協(xié)議標(biāo)準(zhǔn)頭里，而單獨(dú)設(shè)計(jì)一個(gè)擴(kuò)展頭存放拟枚。

IPv6禁止了中間設(shè)備分片薪铜，卸載了一些信息處理流程。最終目的是讓IPv6報(bào)頭成為固定的長(zhǎng)度恩溅，且內(nèi)部字段對(duì)齊隔箍，便于高效預(yù)取或者直接通過(guò)固定硬件處理，從而達(dá)到提高處理性能的目的脚乡。

2.2 TCP

首先蜒滩，我們需要知道TCP在網(wǎng)絡(luò)OSI的七層模型中的第四層——Transport層，IP在第三層——Network層奶稠，ARP在第二層——Data Link層帮掉，在第二層上的數(shù)據(jù)，我們叫Frame窒典，在第三層上的數(shù)據(jù)叫Packet蟆炊，第四層的數(shù)據(jù)叫Segment。

我們程序的數(shù)據(jù)首先會(huì)打到TCP的Segment中瀑志，然后TCP的Segment會(huì)打到IP的Packet中涩搓，然后再打到以太網(wǎng)Ethernet的Frame中，傳到對(duì)端后劈猪，各個(gè)層解析自己的協(xié)議昧甘，然后把數(shù)據(jù)交給更高層的協(xié)議處理。

2.2.1 TCP頭格式

image

注意上圖中的四個(gè)非常重要的東西：

TCP的包是沒(méi)有IP地址的战得，那是IP層上的事充边。但是有源端口和目標(biāo)端口。

一個(gè)TCP連接需要四個(gè)元組來(lái)表示是同一個(gè)連接（src_ip, src_port, dst_ip, dst_port）準(zhǔn)確說(shuō)是五元組常侦，還有一個(gè)是協(xié)議浇冰。但因?yàn)橹皇钦f(shuō)TCP協(xié)議所以只說(shuō)四元組。

• Sequence Number是包的序號(hào)聋亡，用來(lái)解決網(wǎng)絡(luò)包亂序（reordering）問(wèn)題肘习。

• Acknowledgement Number就是ACK——用于確認(rèn)收到，用來(lái)解決不丟包的問(wèn)題坡倔。

• Window又叫Advertised-Window漂佩，也就是著名的滑動(dòng)窗口（Sliding Window）脖含，用于解決流控的。

• TCP Flag 投蝉，也就是包的類(lèi)型养葵，主要是用于操控TCP的狀態(tài)機(jī)的。

2.2.2 TCP狀態(tài)機(jī)

其實(shí)瘩缆，網(wǎng)絡(luò)上的傳輸是沒(méi)有連接的港柜，包括TCP也是一樣的。而TCP所謂的“連接”咳榜，其實(shí)只不過(guò)是在通訊的雙方維護(hù)一個(gè)“連接狀態(tài)”，讓它看上去好像有連接一樣爽锥。所以涌韩，TCP的狀態(tài)變換是非常重要的。

image

image

2.2.3 三次握手四次揮手

建立連接

在TCP/IP協(xié)議中氯夷，TCP協(xié)議提供可靠的連接服務(wù)臣樱，采用三次握手建立一個(gè)連接。

第一次握手：建立連接時(shí)腮考，客戶端發(fā)送syn包(syn=x)到服務(wù)器雇毫，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)踩蔚；

第二次握手：服務(wù)器收到syn包棚放，必須確認(rèn)客戶的SYN（ack=x+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=y）馅闽，即SYN+ACK包飘蚯，此時(shí)服務(wù)器進(jìn)入SYN_RCVD狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN＋ACK包福也，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=y+1)局骤，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)暴凑，完成三次握手峦甩。

完成三次握手，客戶端與服務(wù)器開(kāi)始傳送數(shù)據(jù)现喳，也就是ESTABLISHED狀態(tài)凯傲。

結(jié)束連接

TCP有一個(gè)特別的概念叫做half-close，這個(gè)概念是說(shuō)嗦篱，TCP的連接是全雙工（可以同時(shí)發(fā)送和接收）連接泣洞，因此在關(guān)閉連接的時(shí)候，必須關(guān)閉傳和送兩個(gè)方向上的連接默色∏蚧耍客戶機(jī)給服務(wù)器一個(gè)FIN為1 的TCP報(bào)文狮腿，然后服務(wù)器返回給客戶端一個(gè)確認(rèn)ACK報(bào)文，并且發(fā)送一個(gè)FIN報(bào)文呕诉，當(dāng)客戶機(jī)回復(fù)ACK報(bào)文后（四次握手）缘厢，連接就結(jié)束了。

為什么建立連接是三次握手?jǐn)嚅_(kāi)連接是四次揮手甩挫？

對(duì)于建鏈接的3次握手贴硫，主要是要初始化Sequence Number 的初始值。通信的雙方要互相通知對(duì)方自己的初始化的Sequence Number（縮寫(xiě)為ISN：Inital Sequence Number）——所以叫SYN伊者，全稱(chēng)Synchronize Sequence Numbers英遭。也就上圖中的 x 和 y。這個(gè)號(hào)要作為以后的數(shù)據(jù)通信的序號(hào)亦渗，以保證應(yīng)用層接收到的數(shù)據(jù)不會(huì)因?yàn)榫W(wǎng)絡(luò)上的傳輸?shù)膯?wèn)題而亂序（TCP會(huì)用這個(gè)序號(hào)來(lái)拼接數(shù)據(jù)）挖诸。

對(duì)于4次揮手，其實(shí)仔細(xì)看是2次法精，因?yàn)門(mén)CP是全雙工的多律，所以發(fā)送方和接收方都需要Fin和Ack。只不過(guò)有一方是被動(dòng)的搂蜓，所以看上去就成了所謂的4次揮手狼荞。如果兩邊同時(shí)斷連接，那就會(huì)就進(jìn)入到CLOSING狀態(tài)帮碰，然后到達(dá)TIME_WAIT狀態(tài)相味。

1. 兩次握手是最基本的，一般情況下能保證tcp連接正常進(jìn)行殉挽。

2. 需要第三次握手是為了防止已失效的請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端而產(chǎn)生連接的誤判 攻走。假如沒(méi)有第三次握手，服務(wù)端接收到失效的請(qǐng)求報(bào)文段就會(huì)認(rèn)為連接已建立此再，從而進(jìn)入等待客戶端發(fā)送數(shù)據(jù)的狀態(tài)昔搂。但客戶端并沒(méi)有發(fā)出請(qǐng)求，所以不會(huì)發(fā)送數(shù)據(jù)输拇。于是服務(wù)端就會(huì)一直處于等待狀態(tài)摘符，從而浪費(fèi)資源。

3. 第三次握手失敗后：

*   在第二次握手策吠，服務(wù)器端向客戶端發(fā)送SYN+ACK報(bào)文后逛裤，就會(huì)啟動(dòng)一個(gè)定時(shí)器，等待客戶端返回的ACK報(bào)文猴抹。
    
    
*   如果第三次握手失敗的話带族，客戶端給服務(wù)端返回了ACK報(bào)文，服務(wù)端并不能收到這個(gè)ACK報(bào)文蟀给。那么服務(wù)端就會(huì)啟動(dòng)超時(shí)重傳機(jī)制蝙砌，超過(guò)規(guī)定時(shí)間后重新發(fā)起第二次握手阳堕，向客戶端發(fā)送SYN+ACK。
    
    
*   如果重傳指定次數(shù)到了后择克，仍然未收到ACK應(yīng)答恬总，那么一段時(shí)間后，服務(wù)端會(huì)自動(dòng)關(guān)閉這個(gè)連接肚邢。但客戶端認(rèn)為這個(gè)連接已經(jīng)建立壹堰，如果客戶端向服務(wù)端寫(xiě)數(shù)據(jù)，服務(wù)端將回應(yīng)RST包骡湖、強(qiáng)制關(guān)閉TCP連接贱纠，以防止SYN攻擊。

2.3 TCP滑動(dòng)窗口

如果不了解TCP的滑動(dòng)窗口响蕴，等于不了解TCP協(xié)議谆焊。

TCP必需要解決的可靠傳輸以及包亂序（reordering）的問(wèn)題，所以换途，TCP必需要知道網(wǎng)絡(luò)實(shí)際的數(shù)據(jù)處理帶寬或是數(shù)據(jù)處理速度，這樣才不會(huì)引起網(wǎng)絡(luò)擁塞刽射，導(dǎo)致丟包军拟。所以TCP引入了一些技術(shù)和設(shè)計(jì)來(lái)做網(wǎng)絡(luò)流控，Sliding Window是其中一個(gè)技術(shù)誓禁。 前面我們說(shuō)過(guò)懈息，TCP頭里有一個(gè)字段叫Window，又叫Advertised-Window摹恰，這個(gè)字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)辫继。于是發(fā)送端就可以根據(jù)這個(gè)接收端的處理能力來(lái)發(fā)送數(shù)據(jù)，而不會(huì)導(dǎo)致接收端處理不過(guò)來(lái)俗慈。 為了說(shuō)明滑動(dòng)窗口姑宽，我們需要先看一下TCP緩沖區(qū)的一些數(shù)據(jù)結(jié)構(gòu)：

image

上圖中，我們可以看到：

• 接收端LastByteRead指向了TCP緩沖區(qū)中讀到的位置闺阱，NextByteExpected指向的地方是收到的連續(xù)包的最后一個(gè)位置，LastByteRcved指向的是收到的包的最后一個(gè)位置，我們可以看到中間有些數(shù)據(jù)還沒(méi)有到達(dá)芳杏，所以有數(shù)據(jù)空白區(qū)栓撞。

• 發(fā)送端的LastByteAcked指向了被接收端Ack過(guò)的位置（表示成功發(fā)送確認(rèn)），LastByteSent表示發(fā)出去了赊豌，但還沒(méi)有收到成功確認(rèn)的Ack扛或，LastByteWritten指向的是上層應(yīng)用正在寫(xiě)的地方。

于是：

• 接收端在給發(fā)送端回ACK中會(huì)匯報(bào)自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;

• 而發(fā)送方會(huì)根據(jù)這個(gè)窗口來(lái)控制發(fā)送數(shù)據(jù)的大小碘饼，以保證接收方可以處理熙兔。

下面我們來(lái)看一下發(fā)送方的滑動(dòng)窗口示意圖：

image

上圖中分成了四個(gè)部分悲伶，分別是：（其中那個(gè)黑模型就是滑動(dòng)窗口）

• 1已收到ack確認(rèn)的數(shù)據(jù)。

• 2發(fā)還沒(méi)收到ack的黔姜。

• 3在窗口中還沒(méi)有發(fā)出的（接收方還有空間）拢切。

• 4窗口以外的數(shù)據(jù)（接收方?jīng)]空間）

下面是個(gè)滑動(dòng)后的示意圖（收到36的ack，并發(fā)出了46-51的字節(jié)）：

image

3.1 什么是Http秆吵？

超文本傳輸協(xié)議淮椰，是一個(gè)基于請(qǐng)求與響應(yīng)，無(wú)狀態(tài)的纳寂，應(yīng)用層的協(xié)議主穗，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)毙芜，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)忽媒。設(shè)計(jì)HTTP的初衷是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。

HTTP是一個(gè)客戶端終端（用戶）和服務(wù)器端（網(wǎng)站）請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)腋粥。通過(guò)使用網(wǎng)頁(yè)瀏覽器晦雨、網(wǎng)絡(luò)爬蟲(chóng)或者其它的工具，客戶端發(fā)起一個(gè)HTTP請(qǐng)求到服務(wù)器上指定端口（默認(rèn)端口為80）隘冲。我們稱(chēng)這個(gè)客戶端為用戶代理程序（user agent）闹瞧。應(yīng)答的服務(wù)器上存儲(chǔ)著一些資源，比如HTML文件和圖像展辞。我們稱(chēng)這個(gè)應(yīng)答服務(wù)器為源服務(wù)器奥邮。在用戶代理和源服務(wù)器中間可能存在多個(gè)中間層，比如代理服務(wù)器罗珍、網(wǎng)關(guān)或者隧道（tunnel）洽腺。

盡管TCP/IP協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP協(xié)議中覆旱，并沒(méi)有規(guī)定必須使用它或它支持的層蘸朋。事實(shí)上，HTTP可以在任何互聯(lián)網(wǎng)協(xié)議上扣唱，或其他網(wǎng)絡(luò)上實(shí)現(xiàn)度液。HTTP假定其下層協(xié)議提供可靠的傳輸。因此画舌，任何能夠提供這種保證的協(xié)議都可以被其使用堕担。因此也就是其在TCP/IP協(xié)議族使用TCP作為其傳輸層。

通常曲聂，由HTTP客戶端發(fā)起一個(gè)請(qǐng)求霹购，創(chuàng)建一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽(tīng)客戶端的請(qǐng)求朋腋。一旦收到請(qǐng)求齐疙，服務(wù)器會(huì)向客戶端返回一個(gè)狀態(tài)膜楷，比如"HTTP/1.1 200 OK"，以及返回的內(nèi)容贞奋，如請(qǐng)求的文件赌厅、錯(cuò)誤消息、或者其它信息

3.1.1 URL

URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行痘系，所以見(jiàn)到的基本都是 URL菲嘴。

• URI(Uniform Resource Identifier饿自，統(tǒng)一資源標(biāo)識(shí)符)

• URL(Uniform Resource Locator汰翠，統(tǒng)一資源定位符)

• URN(Uniform Resource Name，統(tǒng)一資源名稱(chēng))

image

3.1.2 請(qǐng)求報(bào)文和響應(yīng)報(bào)文

請(qǐng)求報(bào)文 響應(yīng)報(bào)文

image

image

3.1.3 狀態(tài)碼

服務(wù)器返回的 響應(yīng)報(bào)文 中第一行為狀態(tài)行昭雌，包含了狀態(tài)碼以及原因短語(yǔ)复唤，用來(lái)告知客戶端請(qǐng)求的結(jié)果。

3.1.4 工作原理

HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請(qǐng)求Web頁(yè)面烛卧，以及服務(wù)器如何把Web頁(yè)面?zhèn)魉徒o客戶端佛纫。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型∽芊牛客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文呈宇，請(qǐng)求報(bào)文包含請(qǐng)求的方法、URL局雄、協(xié)議版本甥啄、請(qǐng)求頭部和請(qǐng)求數(shù)據(jù)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)炬搭，響應(yīng)的內(nèi)容包括協(xié)議的版本蜈漓、成功或者錯(cuò)誤代碼穆桂、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)融虽。

以下是 HTTP 請(qǐng)求/響應(yīng)的步驟：

1. 客戶端連接到Web服務(wù)器：一個(gè)HTTP客戶端享完，通常是瀏覽器，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接有额。例如般又，http://www.baidu.com。

2. 發(fā)送HTTP請(qǐng)求：通過(guò)TCP套接字谆吴，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文倒源，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部句狼、空行和請(qǐng)求數(shù)據(jù)4部分組成笋熬。

3. 服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)：Web服務(wù)器解析請(qǐng)求，定位請(qǐng)求資源腻菇。服務(wù)器將資源復(fù)本寫(xiě)到TCP套接字胳螟，由客戶端讀取。一個(gè)響應(yīng)由狀態(tài)行筹吐、響應(yīng)頭部糖耸、空行和響應(yīng)數(shù)據(jù)4部分組成。

4. 釋放連接TCP連接：若connection 模式為close丘薛，則服務(wù)器主動(dòng)關(guān)閉TCP連接嘉竟，客戶端被動(dòng)關(guān)閉連接，釋放TCP連接;若connection 模式為keepalive洋侨，則該連接會(huì)保持一段時(shí)間舍扰，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求;

5. 客戶端瀏覽器解析HTML內(nèi)容：客戶端瀏覽器首先解析狀態(tài)行，查看表明請(qǐng)求是否成功的狀態(tài)代碼希坚。然后解析每一個(gè)響應(yīng)頭边苹，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集〔蒙客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML个束，根據(jù)HTML的語(yǔ)法對(duì)其進(jìn)行格式化，并在瀏覽器窗口中顯示聊疲。

例如：在瀏覽器地址欄鍵入U(xiǎn)RL茬底，按下回車(chē)之后會(huì)經(jīng)歷以下流程：

1. 瀏覽器向 DNS 服務(wù)器請(qǐng)求解析該 URL 中的域名所對(duì)應(yīng)的 IP 地址;

2. 解析出 IP 地址后，根據(jù)該 IP 地址和默認(rèn)端口 80获洲，和服務(wù)器建立TCP連接;

3. 瀏覽器發(fā)出讀取文件(URL 中域名后面部分對(duì)應(yīng)的文件)的HTTP 請(qǐng)求阱表，該請(qǐng)求報(bào)文作為 TCP 三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給服務(wù)器;

4. 服務(wù)器對(duì)瀏覽器請(qǐng)求作出響應(yīng)，并把對(duì)應(yīng)的 html 文本發(fā)送給瀏覽器;

5. 釋放 TCP連接;

6. 瀏覽器將該 html 文本并顯示內(nèi)容;

image

基于 請(qǐng)求-響應(yīng) 的模式

HTTP協(xié)議規(guī)定,請(qǐng)求從客戶端發(fā)出,最后服務(wù)器端響應(yīng)該請(qǐng)求并 返回。換句話說(shuō),肯定是先從客戶端開(kāi)始建立通信的,服務(wù)器端在沒(méi)有 接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)

image

無(wú)狀態(tài)保存

HTTP是一種不保存狀態(tài),即無(wú)狀態(tài)(stateless)協(xié)議捶枢。HTTP協(xié)議 自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存握截。也就是說(shuō)在HTTP這個(gè) 級(jí)別,協(xié)議對(duì)于發(fā)送過(guò)的請(qǐng)求或響應(yīng)都不做持久化處理。無(wú)狀態(tài)不代表 HTTP 不能保持 TCP 連接烂叔，更不能代表 HTTP 使用的是 UDP 協(xié)議(無(wú)連接)谨胞。

image

使用HTTP協(xié)議,每當(dāng)有新的請(qǐng)求發(fā)送時(shí),就會(huì)有對(duì)應(yīng)的新響應(yīng)產(chǎn) 生。協(xié)議本身并不保留之前一切的請(qǐng)求或響應(yīng)報(bào)文的信息蒜鸡。這是為了更快地處理大量事務(wù),確保協(xié)議的可伸縮性,而特意把HTTP協(xié)議設(shè)計(jì)成 如此簡(jiǎn)單的胯努。可是,隨著Web的不斷發(fā)展,因無(wú)狀態(tài)而導(dǎo)致業(yè)務(wù)處理變得棘手 的情況增多了逢防。比如用戶登錄到一家購(gòu)物網(wǎng)站,即使他跳轉(zhuǎn)到該站的 其他頁(yè)面后,也需要能繼續(xù)保持登錄狀態(tài)叶沛。針對(duì)這個(gè)實(shí)例,網(wǎng)站為了能夠掌握是誰(shuí)送出的請(qǐng)求,需要保存用戶的狀態(tài)。HTTP/1.1雖然是無(wú)狀態(tài)協(xié)議,但為了實(shí)現(xiàn)期望的保持狀態(tài)功能, 于是引入了Cookie技術(shù)忘朝。有了Cookie再用HTTP協(xié)議通信,就可以管理狀態(tài)了灰署。

無(wú)連接

無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求局嘁，并收到客戶的應(yīng)答后溉箕，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間悦昵，并且可以提高并發(fā)性能肴茄，不能和每個(gè)用戶建立長(zhǎng)久的連接，請(qǐng)求一次響應(yīng)一次但指，服務(wù)端和客戶端就中斷了寡痰。但是無(wú)連接有兩種方式，早期的http協(xié)議是一個(gè)請(qǐng)求一個(gè)響應(yīng)之后棋凳，直接就斷開(kāi)了拦坠，但是現(xiàn)在的http協(xié)議1.1版本不是直接就斷開(kāi)了，而是等幾秒鐘贫橙，如果用戶在這幾秒鐘之內(nèi)有新的請(qǐng)求贪婉，那么還是通過(guò)之前的連接通道來(lái)收發(fā)消息反粥，如果過(guò)了這幾秒鐘用戶沒(méi)有發(fā)送新的請(qǐng)求卢肃，那么就會(huì)斷開(kāi)連接，這樣可以提高效率才顿，減少短時(shí)間內(nèi)建立連接的次數(shù)莫湘，因?yàn)榻⑦B接也是耗時(shí)的，默認(rèn)的好像是3秒郑气，這個(gè)時(shí)間是可以通過(guò)后端調(diào)整的幅垮，所以可以根據(jù)網(wǎng)站用戶的行為來(lái)分析統(tǒng)計(jì)出一個(gè)最優(yōu)的等待時(shí)間。

可見(jiàn)尾组，HTTP不是字面意義上的沒(méi)有連接忙芒，事實(shí)上示弓，這個(gè)定義也符合HTTP短連接的定義，但無(wú)連接強(qiáng)調(diào)的是HTTP的特性呵萨，短連接可理解為一種實(shí)現(xiàn)奏属。

長(zhǎng)連接和短連接

HTTP 對(duì) TCP 連接的使用，分為兩種方式：俗稱(chēng)“短連接”和“長(zhǎng)連接”（“Keep-Alive”或“Persistent Connection”）

長(zhǎng)連接:當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后潮峦，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉囱皿，客戶端再次訪問(wèn)這個(gè)服務(wù)器時(shí)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接忱嘹。Keep-Alive不會(huì)永久保持連接嘱腥，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間拘悦。實(shí)現(xiàn)長(zhǎng)連接需要客戶端和服務(wù)端都支持長(zhǎng)連接齿兔。

• HTTP/0.9：最早發(fā)布的1991年0.9版，該時(shí)期的HTTP協(xié)議十分簡(jiǎn)單础米，只支持Get請(qǐng)求愧驱，采用短連接的方式，也就是說(shuō)椭盏，客戶端和服務(wù)器每進(jìn)行一次HTTP操作组砚，就建立一次連接，任務(wù)結(jié)束就中斷連接掏颊。當(dāng)客戶端瀏覽器訪問(wèn)的某個(gè)HTML或其他類(lèi)型的Web頁(yè)中包含有其他的Web資源（如JavaScript文件糟红、圖像文件、CSS文件等）乌叶，每遇到這樣一個(gè)Web資源盆偿，瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話。

• HTTP/1.0：1996年發(fā)布准浴，默認(rèn)使用短連接事扭，提出長(zhǎng)連接（也叫持久連接）的概念，但當(dāng)時(shí)僅提供初步的支持乐横。

• HTTP/1.1：1999年發(fā)布求橄，默認(rèn)使用長(zhǎng)連接，用以保持連接特性葡公。使用長(zhǎng)連接的HTTP協(xié)議罐农，會(huì)在響應(yīng)頭加入這行代碼：Connection:keep-alive

如果HTTP1.1版本的HTTP請(qǐng)求報(bào)文不希望使用長(zhǎng)連接，則要在HTTP請(qǐng)求報(bào)文首部加上Connection: close催什。

短連接:客戶端和服務(wù)器每進(jìn)行一次HTTP操作涵亏，就建立一次連接，任務(wù)結(jié)束就中斷連接。雙方任意都可以發(fā)起close操作气筋，一般都是client先發(fā)起close操作拆内。優(yōu)點(diǎn)是：管理起來(lái)比較簡(jiǎn)單，存在的連接都是有用的連接宠默，不需要額外的控制手段矛纹。也可以這樣說(shuō)：短連接是指Socket連接后發(fā)送后接收完數(shù)據(jù)后馬上斷開(kāi)連接。

HTTP協(xié)議的長(zhǎng)連接和短連接光稼，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接或南。

TCP短連接長(zhǎng)連接都由客戶端發(fā)起，而TCP長(zhǎng)連接的卑活功能主要為服務(wù)器應(yīng)用提供采够。如果客戶端已經(jīng)消失而連接未斷開(kāi)，則會(huì)使得服務(wù)器上保留一個(gè)半開(kāi)放的連接冰垄，而服務(wù)器又在等待來(lái)自客戶端的數(shù)據(jù)蹬癌，此時(shí)服務(wù)器將永遠(yuǎn)等待客戶端的數(shù)據(jù)。焙绮瑁活功能就是試圖在服務(wù)端器端檢測(cè)到這種半開(kāi)放的連接逝薪，并根據(jù)響應(yīng)決定是否關(guān)閉連接。因?yàn)槎踢B接蝴罪、長(zhǎng)連接的實(shí)現(xiàn)在HTTP之外董济，與HTTP無(wú)關(guān)，從HTTP自身來(lái)看要门，HTTP依然是無(wú)連接的虏肾。

3.1.5 GET和POST

image