作者：Vamei 出處：http://www.cnblogs.com/vamei

1. OSI模型

• 物理層(physical layer)：光纖、電纜或者電磁波等真實(shí)存在的物理媒介。0/1信號(hào)
• 連接層(link layer)：在連接層，信息以幀(frame)為單位傳輸。一串0/1序列，包括了收信地址(Source, SRC)和送信地址(Destination, DST)，還有能夠探測(cè)錯(cuò)誤的校驗(yàn)序列(Frame Check Sequence)及符合更高層協(xié)議的數(shù)據(jù)信息。以太網(wǎng)(Ethernet)和WiFi是現(xiàn)在最常見的連接層協(xié)議。類似于郵差，收到信封。
• 網(wǎng)絡(luò)層(network layer)：不同的社區(qū)之間通信需要用到路由器。路由器能夠：1. 能從物理層上在兩個(gè)網(wǎng)絡(luò)的接收和發(fā)送0/1序列，2. 能同時(shí)理解兩種網(wǎng)絡(luò)的幀格式。IP協(xié)議。路由器和計(jì)算機(jī)都懂得IP協(xié)議。類似于郵局。
• 傳輸層(transport layer)：找到了某一臺(tái)計(jì)算機(jī)，靠傳輸層判斷是交給哪個(gè)進(jìn)程。TCP/UDP協(xié)議。TCP協(xié)議還有控制網(wǎng)絡(luò)交通等功能。
• 應(yīng)用層(application layer)：應(yīng)用層協(xié)議是對(duì)信件內(nèi)容進(jìn)一步的用語規(guī)范。應(yīng)用層的協(xié)議包括用于Web瀏覽的HTTP協(xié)議，用于傳輸文件的FTP協(xié)議，用于Email的IMAP等等。

2. 連接層

以太網(wǎng)和WiFi是連接層的兩種協(xié)議。在連接層，信息以幀(frame)為單位傳輸。幀像信封一樣將數(shù)據(jù)(payload)包裹起來，并注明收信地址和送信地址。連接層實(shí)現(xiàn)了“本地社區(qū)”的通信。
幀本身是一段有限的0/1序列。它可以分為頭部、數(shù)據(jù)(Payload)和尾部三部分:

幀按照上面的順序從頭到尾依次被發(fā)送/接收。

• 幀的最初7個(gè)byte被稱為序言(preamble)。它的每個(gè)byte都是0xAA(這里是十六進(jìn)制，也就是二進(jìn)制的10101010)。為了與發(fā)送設(shè)備的頻率一致，這個(gè)過程就叫做時(shí)鐘復(fù)原(recover the clock)。
• 幀的起始信號(hào)(SFD, start frame delimiter)。SFD是固定的值0xAB。
• 緊隨SFD之后的是6 byte的目的地(DST, destination)和6 byte的發(fā)出地(SRC, source)。對(duì)地址的“本地描述”，也就是MAC地址。MAC地址是物理設(shè)備自帶的序號(hào)，只能在同一個(gè)以太網(wǎng)中被識(shí)別 。
• 頭部的最后一個(gè)區(qū)域是Type，用以說明數(shù)據(jù)部分的類型。(比如0x0800為IPv4，0x0806為ARP)。
• 數(shù)據(jù)一般包含有符合更高層協(xié)議的數(shù)據(jù)，比如IP包。連接層協(xié)議本身并不在乎數(shù)據(jù)是什么，它只負(fù)責(zé)傳輸。注意，數(shù)據(jù)尾部可能填充有一串0(PAD區(qū)域)。原因是數(shù)據(jù)需要超過一定的最小長(zhǎng)度。
• 跟隨在數(shù)據(jù)之后的是校驗(yàn)序列(FCS, Frame Check Sequence)。校驗(yàn)序列是為了檢驗(yàn)數(shù)據(jù)的傳輸是否發(fā)生錯(cuò)誤。FCS采用了CRC(Cyclic Redundancy Check)算法。

2.1 集線器(Hub) vs. 交換器(Switch)

以太網(wǎng)使用集線器或者交換器將幀從發(fā)出地傳送到目的地。一臺(tái)集線器或交換器上有多個(gè)端口，每個(gè)端口都可以連接一臺(tái)計(jì)算機(jī)(或其他設(shè)備)。
一臺(tái)電腦將幀發(fā)送到集線器，集線器會(huì)將幀轉(zhuǎn)發(fā)到所有其他的端口。每臺(tái)計(jì)算機(jī)檢查自己的MAC地址是不是符合DST。如果不是，則保持沉默。缺點(diǎn)在于：1. 相當(dāng)于廣播，不安全。 2. 多個(gè)客戶端向集線器同時(shí)發(fā)送消息時(shí)，會(huì)產(chǎn)生沖突。
交換器克服集線器的缺陷。交換器記錄有各個(gè)設(shè)備的MAC地址。當(dāng)幀發(fā)送到交換器時(shí)，交換器會(huì)檢查DST，然后將幀只發(fā)送到對(duì)應(yīng)端口。交換器允許多路同時(shí)通信。由于交換器的優(yōu)越性，交換器基本上取代了集線器。但比較老的以太網(wǎng)還有可能在使用集線器。

交換機(jī)對(duì)MAC地址的記錄表也是逐漸生成的。收到一個(gè)有frame的時(shí)候，記錄下發(fā)出地的端口和MAC地址，如果MAC表為空，則像每個(gè)端口轉(zhuǎn)播這個(gè)frame，等到正確的機(jī)器接收到frame并回復(fù)時(shí)就知道了接受地的端口和MAC地址對(duì)應(yīng)。

2.2 WiFi

WiFi的工作方式與集線器連接下的以太網(wǎng)類似。一個(gè)WiFi設(shè)備會(huì)向所有的WiFi設(shè)備發(fā)送幀，其它的WiFi設(shè)備檢查自己是否符合DST。由于WiFi采取無線電信號(hào)，所以很難像交換器一樣定向發(fā)送，所以WiFi的安全性很值得關(guān)注。WiFi采用加密的方法來實(shí)現(xiàn)信息的安全性。

3. 網(wǎng)絡(luò)層

網(wǎng)絡(luò)層(network layer)是實(shí)現(xiàn)互聯(lián)網(wǎng)的最重要的一層。正是在網(wǎng)絡(luò)層面上，各個(gè)局域網(wǎng)根據(jù)IP協(xié)議相互連接，最終構(gòu)成覆蓋全球的Internet。
IP數(shù)據(jù)包是符合IP協(xié)議的信息(也就是0/1序列)，IP包分為頭部(header)和數(shù)據(jù)(Data)兩部分。數(shù)據(jù)部分是要傳送的信息，頭部是為了能夠?qū)崿F(xiàn)傳輸而附加的信息。

3.1 IP包

IPv4

3.2 網(wǎng)卡與路由器

IP地址實(shí)際上識(shí)別的是網(wǎng)卡(NIC, Network Interface Card)。網(wǎng)卡是計(jì)算機(jī)的一個(gè)硬件，它在接收到網(wǎng)路信息之后，將信息交給計(jì)算機(jī)(處理器/內(nèi)存)。當(dāng)計(jì)算機(jī)需要發(fā)送信息的時(shí)候，也要通過網(wǎng)卡發(fā)送。
路由器(router)實(shí)際上就是一臺(tái)配備有多個(gè)網(wǎng)卡的專用電腦。它讓網(wǎng)卡接入到不同的網(wǎng)絡(luò)中。

3.3 IP包傳輸

IP包的傳輸要通過路由器的接力。每一個(gè)主機(jī)和路由中都存有一個(gè)路由表(routing table)。路由表根據(jù)目的地的IP地址，規(guī)定了等待發(fā)送的IP包所應(yīng)該走的路線。
IP包可以進(jìn)一步接力，到達(dá)更遠(yuǎn)的主機(jī)。IP包從主機(jī)出發(fā)，根據(jù)沿途路由器的routing table指導(dǎo)，在router間接力。IP包最終到達(dá)某個(gè)router，這個(gè)router與目標(biāo)主機(jī)位于一個(gè)局域網(wǎng)中，可以直接建立連接層的通信。最后，IP包被送到目標(biāo)主機(jī)。這樣一個(gè)過程叫做routing。
整個(gè)過程中，IP包不斷被主機(jī)和路由封裝入幀(信封)并拆開，然后借助連接層，在局域網(wǎng)的各個(gè)NIC之間傳送幀。整個(gè)過程中，我們的IP包的內(nèi)容保持完整，沒有發(fā)生變化。最終的效果是一個(gè)IP包從一個(gè)主機(jī)傳送到另一個(gè)主機(jī)。利用IP包，我們不需要去操心底層(比如連接層)發(fā)生了什么。

3.4 ARP協(xié)議

每一臺(tái)主機(jī)和路由都能了解局域網(wǎng)內(nèi)的IP地址和MAC地址的對(duì)應(yīng)關(guān)系，這是實(shí)現(xiàn)IP包封裝(encapsulation)到幀的基本條件。IP地址與MAC地址的對(duì)應(yīng)是通過ARP協(xié)議傳播到局域網(wǎng)的每個(gè)主機(jī)和路由。每一臺(tái)主機(jī)或路由中都有一個(gè)ARP cache，用以存儲(chǔ)局域網(wǎng)內(nèi)IP地址和MAC地址如何對(duì)應(yīng)。
ARP協(xié)議(ARP介于連接層和網(wǎng)絡(luò)層之間，ARP包需要包裹在一個(gè)幀中)的工作方式如下：主機(jī)會(huì)發(fā)出一個(gè)ARP包，該ARP包中包含有自己的IP地址和MAC地址。通過ARP包，主機(jī)以廣播的形式詢問局域網(wǎng)上所有的主機(jī)和路由：我是IP地址xxxx，我的MAC地址是xxxx，有人知道199.165.146.4的MAC地址嗎？擁有該IP地址的主機(jī)會(huì)回復(fù)發(fā)出請(qǐng)求的主機(jī)：哦，我知道，這個(gè)IP地址屬于我的一個(gè)NIC，它的MAC地址是xxxxxx。由于發(fā)送ARP請(qǐng)求的主機(jī)采取的是廣播形式，并附帶有自己的IP地址和MAC地址，其他的主機(jī)和路由會(huì)同時(shí)檢查自己的ARP cache，如果不符合，則更新自己的ARP cache。
這樣，經(jīng)過幾次ARP請(qǐng)求之后，ARP cache會(huì)達(dá)到穩(wěn)定。如果局域網(wǎng)上設(shè)備發(fā)生變動(dòng)，ARP重復(fù)上面過程。

3.5 Routing table

Routing table描述了網(wǎng)絡(luò)的拓?fù)?topology)結(jié)構(gòu)。
一種用來生成routing table的協(xié)議是RIP(Routing Information Protocol)。它通過距離來決定routing table，所以屬于distance-vector protocol。對(duì)于RIP來說，所謂的距離是從出發(fā)地到目的地途徑的路由器數(shù)目(hop number)。

一個(gè)路由向其他路由廣播它的table，其他路由根據(jù)收到的包更新自己的table

RIP出于技術(shù)上的原因(looping hops)，認(rèn)為距離超過15的IP不可到達(dá)。所以RIP更多用于互聯(lián)網(wǎng)的一部分(比如整個(gè)中國(guó)電信的網(wǎng)絡(luò))。這樣一個(gè)互聯(lián)網(wǎng)的部分往往屬于同一個(gè)ISP或者有同一個(gè)管理機(jī)構(gòu)，所以叫做自治系統(tǒng)(AS,autonomous system)。自治系統(tǒng)內(nèi)部的主機(jī)和路由根據(jù)通向外部的邊界路由器來和其它的自治系統(tǒng)通信。各個(gè)邊界路由器之間通過BGP(Border Gateway Protocol)來生成自己前往其它AS的routing table，而自治系統(tǒng)內(nèi)部則參照邊界路由器，使用RIP來決定routing table。BGP的基本工作過程與RIP類似，但在考慮距離的同時(shí)，也權(quán)衡比如政策、連接性能等其他因素，再?zèng)Q定交通的走向(routing table)。

3.6 IP協(xié)議

IP協(xié)議是"Best Effort"式的，IP傳輸是不可靠的。但這樣的設(shè)計(jì)成就了IP協(xié)議的效率。

3.7 ICMP協(xié)議

ICMP(Internet Control Message Protocol)是介于網(wǎng)絡(luò)層和傳輸層的協(xié)議。它的主要功能是傳輸網(wǎng)絡(luò)診斷信息。

常見的ICMP包類型

回音
回音(Echo)屬于咨詢信息。ping命令就是利用了該類型的ICMP包。當(dāng)使用ping命令的時(shí)候，將向目標(biāo)主機(jī)發(fā)送Echo-詢問類型的ICMP包，而目標(biāo)主機(jī)在接收到該ICMP包之后，會(huì)回復(fù)Echo-回答類型的ICMP包，并將詢問ICMP包包含在數(shù)據(jù)部分。ping命令是我們進(jìn)行網(wǎng)絡(luò)排查的一個(gè)重要工具。如果一個(gè)IP地址可以通過ping命令收到回復(fù)，那么其他的網(wǎng)絡(luò)協(xié)議通信方式也很有可能成功。

源頭冷卻
源頭冷卻(source quench)屬于錯(cuò)誤信息。如果某個(gè)主機(jī)快速的向目的地傳送數(shù)據(jù)，而目的地主機(jī)沒有匹配的處理能力，目的地主機(jī)可以向出發(fā)主機(jī)發(fā)出該類型的ICMP包，提醒出發(fā)主機(jī)放慢發(fā)送速度(請(qǐng)溫柔一點(diǎn)吧)。

目的地?zé)o法到達(dá)
目的地?zé)o法到達(dá)(Destination Unreachable)屬于錯(cuò)誤信息。如果一個(gè)路由器接收到一個(gè)沒辦法進(jìn)一步接力的IP包，它會(huì)向出發(fā)主機(jī)發(fā)送該類型的ICMP包。比如當(dāng)IP包到達(dá)最后一個(gè)路由器，路由器發(fā)現(xiàn)目的地主機(jī)down機(jī)，就會(huì)向出發(fā)主機(jī)發(fā)送目的地?zé)o法到達(dá)(Destination Unreachable)類型的ICMP包。目的地?zé)o法到達(dá)還可能有其他的原因，比如不存在接力路徑，比如不被接收的端口號(hào)等等。

超時(shí)
超時(shí)(Time Exceeded)屬于錯(cuò)誤信息。IPv4中的Time to Live(TTL)和IPv6中的Hop Limit會(huì)隨著經(jīng)過的路由器而遞減，當(dāng)這個(gè)區(qū)域值減為0時(shí)，就認(rèn)為該IP包超時(shí)(Time Exceeded)。Time Exceeded就是TTL減為0時(shí)的路由器發(fā)給出發(fā)主機(jī)的ICMP包，通知它發(fā)生了超時(shí)錯(cuò)誤。
traceroute就利用了這種類型的ICMP包。traceroute命令用來發(fā)現(xiàn)IP接力路徑(route)上的各個(gè)路由器。它向目的地發(fā)送IP包，第一次的時(shí)候，將TTL設(shè)置為1，引發(fā)第一個(gè)路由器的Time Exceeded錯(cuò)誤。這樣，第一個(gè)路由器回復(fù)ICMP包，從而讓出發(fā)主機(jī)知道途徑的第一個(gè)路由器的信息。隨后TTL被設(shè)置為2、3、4，...，直到到達(dá)目的主機(jī)。這樣，沿途的每個(gè)路由器都會(huì)向出發(fā)主機(jī)發(fā)送ICMP包來匯報(bào)錯(cuò)誤。traceroute將ICMP包的信息打印在屏幕上，就是接力路徑的信息了。

重新定向
重新定向(redirect)屬于錯(cuò)誤信息。當(dāng)一個(gè)路由器收到一個(gè)IP包，對(duì)照其routing table，發(fā)現(xiàn)自己不應(yīng)該收到該IP包，它會(huì)向出發(fā)主機(jī)發(fā)送重新定向類型的ICMP，提醒出發(fā)主機(jī)修改自己的routing table。

4. 傳輸層

4.1 UDP

UDP(User Datagram Protocol)傳輸與IP傳輸非常類似。你可以將UDP協(xié)議看作IP協(xié)議暴露在傳輸層的一個(gè)接口。UDP協(xié)議同樣以數(shù)據(jù)包(datagram)的方式傳輸，它的傳輸方式也是"Best Effort"的，所以UDP協(xié)議也是不可靠的(unreliable)。
UDP的數(shù)據(jù)包同樣分為頭部(header)和數(shù)據(jù)(payload)兩部分。UDP是傳輸層(transport layer)協(xié)議，這意味著UDP的數(shù)據(jù)包需要經(jīng)過IP協(xié)議的封裝(encapsulation)，然后通過IP協(xié)議傳輸?shù)侥康碾娔X。隨后UDP包在目的電腦拆封，并將信息送到相應(yīng)端口的緩存中。

4.2 TCP

TCP

TCP協(xié)議是傳輸層協(xié)議，實(shí)現(xiàn)的是端口到端口(port)的通信。更進(jìn)一步，TCP協(xié)議虛擬了文本流(byte stream)的通信。
TCP協(xié)議確保了數(shù)據(jù)到達(dá)的順序與文本流順序相符。
是TCP協(xié)議所規(guī)定的片段(segment)。與之前的一個(gè)IP或者UDP數(shù)據(jù)包類似，一個(gè)TCP片段同樣分為頭部(header)和數(shù)據(jù)(payload)兩部分
(給文本流分段是在發(fā)送主機(jī)完成的，而碎片化是在網(wǎng)絡(luò)中的路由器完成的。路由器要處理許多路的通信，所以相當(dāng)繁忙。文本流提前在發(fā)送主機(jī)分好段，可以避免在路由器上執(zhí)行碎片化，可大大減小網(wǎng)絡(luò)負(fù)擔(dān))

TCP的補(bǔ)救方法是，在每收到一個(gè)正確的、符合次序的片段之后，就向發(fā)送方(也就是連接的另一段)發(fā)送一個(gè)特殊的TCP片段，用來知會(huì)(ACK，acknowledge)發(fā)送方：我已經(jīng)收到那個(gè)片段了。這個(gè)特殊的TCP片段叫做ACK回復(fù)。如果一個(gè)片段序號(hào)為L(zhǎng)，對(duì)應(yīng)ACK回復(fù)有回復(fù)號(hào)L+1，也就是接收方期待接收的下一個(gè)發(fā)送片段的序號(hào)。如果發(fā)送方在一定時(shí)間等待之后，還是沒有收到ACK回復(fù)，那么它推斷之前發(fā)送的片段一定發(fā)生了異常。發(fā)送方會(huì)重復(fù)發(fā)送(retransmit)那個(gè)出現(xiàn)異常的片段，等待ACK回復(fù)，如果還沒有收到，那么再重復(fù)發(fā)送原片段... 直到收到該片段對(duì)應(yīng)的ACK回復(fù)(回復(fù)號(hào)為L(zhǎng)+1的ACK)。
當(dāng)發(fā)送方收到ACK回復(fù)時(shí)，它看到里面的回復(fù)號(hào)為L(zhǎng)+1，也就是發(fā)送方下一個(gè)應(yīng)該發(fā)送的TCP片段序號(hào)。發(fā)送方推斷出之前的片段已經(jīng)被正確的接收，隨后發(fā)出L+1號(hào)片段。ACK回復(fù)也有可能丟失。對(duì)于發(fā)送方來說，這和接收方拒絕發(fā)送ACK回復(fù)是一樣的。發(fā)送方會(huì)重復(fù)發(fā)送，而接收方接收到已知會(huì)過的片段，推斷出ACK回復(fù)丟失，會(huì)重新發(fā)送ACK回復(fù)。

通過ACK回復(fù)和重新發(fā)送機(jī)制，TCP協(xié)議將片段傳輸變得可靠。

滑窗(sliding window)被同時(shí)應(yīng)用于接收方和發(fā)送方，以解決以上問題。發(fā)送方和接收方各有一個(gè)滑窗。當(dāng)片段位于滑窗中時(shí)，表示TCP正在處理該片段?；爸锌梢杂卸鄠€(gè)片段，也就是可以同時(shí)處理多個(gè)片段?；霸酱螅酱蟮幕巴瑫r(shí)處理的片段數(shù)目越多(當(dāng)然，計(jì)算機(jī)也必須分配出更多的緩存供滑窗使用)。

網(wǎng)絡(luò)層在邏輯上提供了端口的概念。一個(gè)IP地址可以有多個(gè)端口。一個(gè)具體的端口需要IP地址和端口號(hào)共同確定(我們記為IP:port的形式)。一個(gè)連接為兩個(gè)IP:port之間建立TCP通信。
參與連接的如果是兩臺(tái)電腦，那么兩臺(tái)電腦操作系統(tǒng)的TCP模塊負(fù)責(zé)建立連接。每個(gè)連接有四個(gè)參數(shù)(兩個(gè)IP，兩個(gè)端口)，來表明“誰在和誰通話”。每臺(tái)電腦都會(huì)記錄有這四個(gè)參數(shù)，以確定是哪一個(gè)連接。如果這四個(gè)參數(shù)完全相同，則為同一連接；如果這四個(gè)參數(shù)有一個(gè)不同，即為不同的連接。這意味著，同一個(gè)端口上可以有多個(gè)連接。

ACK（一位）回復(fù)“附著”在發(fā)送的數(shù)據(jù)片段中。TCP協(xié)議是雙向的。比如A和B兩個(gè)電腦。ACK回復(fù)是接收方回復(fù)給發(fā)送方 (比如A發(fā)送給B， B回復(fù)A)。但同時(shí)，B也可以是發(fā)送方，B有可能有數(shù)據(jù)發(fā)送給A，所以B就把ACK回復(fù)附著在它要發(fā)送給A的數(shù)據(jù)片段的頭部。這樣可以減少ACK所占用的交通流量。一個(gè)片段可以只包含ACK回復(fù)。一個(gè)純粹的ACK回復(fù)片段不傳送文本流，所以不消耗序列號(hào)。如果有下一個(gè)正常的數(shù)據(jù)片段，它的序號(hào)將與純粹ACK回復(fù)片段的序號(hào)相同。(ACK回復(fù)還可以“附著”在SYN片段和FIN片段)

TCP連接建立

TCP連接從無到有需要一個(gè)建立連接的過程。建立連接的最重要目是讓連接的雙方交換初始序號(hào)(ISN, Initial Sequence Number)。根據(jù)TCP協(xié)議的規(guī)定，文本流的第一個(gè)片段的序號(hào)不能是確定的數(shù)字(比如說1)。連接的雙方各自隨機(jī)生成自己的ISN，然后再利用的一定方式讓對(duì)方了解。這樣的規(guī)定是出于TCP連接安全考慮：如果以一個(gè)確定的數(shù)字作為初始的TCP序號(hào)，那么其他人很容易猜出接下來的序列號(hào)，并按照正確的序號(hào)發(fā)送“偽裝”的TCP片段，以插入到文本流中。

ISN交換是通過SYN片段實(shí)現(xiàn)的。SYN片段由頭部的SYN位表明，它的序號(hào)為發(fā)送方的ISN。該片段由連接的一方首先發(fā)給給另一方，我們將發(fā)送SYN的一方稱為客戶(client)，而接收SYN的一方稱為服務(wù)器(server)。我們使用ISN(c)表示client一方的ISN，使用ISN(s)表示server一方的ISN。隨后，接收到SYN的server需要回復(fù)ACK，并發(fā)送出包含有server的ISN的SYN片段。經(jīng)典的TCP三次握手(three-way handshaking)。

一個(gè)連接建立之后，連接兩端的進(jìn)程可以利用該連接進(jìn)行通信。當(dāng)連接的一方覺得“我講完了”，它可以終結(jié)連接中發(fā)送到對(duì)方方向的通信。連接最終通過四次握手(four-way handshaking)的方式終結(jié)，連接終結(jié)使用的是特殊片段FIN(FIN位為1的片段)。

end

累計(jì)ACK減少了TCP傳輸過程中所需的ACK流量。通過流量管理，TCP連接兩端的工作能力可以匹配，從而減少不不要的傳輸浪費(fèi)。累計(jì)ACK和流量控制都是TCP協(xié)議的重要特征。

快速重新發(fā)送機(jī)制利用重復(fù)的ACK來提示空洞的存在。當(dāng)重復(fù)次數(shù)達(dá)到閾值時(shí)，認(rèn)為空洞對(duì)應(yīng)的片段在網(wǎng)絡(luò)中丟失?？焖僦匦掳l(fā)送機(jī)制提高了檢測(cè)丟失片段的效率，往往可以在超時(shí)之前探測(cè)到丟失片段，并重復(fù)發(fā)送丟失的片段。

在TCP協(xié)議中，我們使用連接記錄TCP兩端的狀態(tài)，使用編號(hào)和分段實(shí)現(xiàn)了TCP傳輸?shù)挠行?，使用advertised window來實(shí)現(xiàn)了發(fā)送方和接收方處理能力的匹配，并使用重復(fù)發(fā)送來實(shí)現(xiàn)TCP傳輸?shù)目煽啃?。我們只需要將TCP片段包裝成IP包，扔到網(wǎng)絡(luò)中就可以了。TCP協(xié)議的相關(guān)模塊會(huì)幫我們處理各種可能出現(xiàn)的問題(比如排序，比如TCP片段丟失等等)。最初的TCP協(xié)議就是由上述的幾大塊構(gòu)成的。

4. 應(yīng)用層

4.1DNS

域名(domain name)是IP地址的代號(hào)。域名通常是由字符構(gòu)成的。對(duì)于人類來說，字符構(gòu)成的域名，比如www.yahoo.com，要比純粹數(shù)字構(gòu)成的IP地址(106.10.170.118)容易記憶。域名解析系統(tǒng)(DNS, domain name system)就負(fù)責(zé)將域名翻譯為對(duì)應(yīng)的IP地址。
域名和IP地址的對(duì)應(yīng)關(guān)系存儲(chǔ)在DNS服務(wù)器(DNS server)中。所謂的DNS服務(wù)器，是指在網(wǎng)絡(luò)中進(jìn)行域名解析的一些服務(wù)器(計(jì)算機(jī))。這些服務(wù)器都有自己的IP地址，并使用DNS協(xié)議(DNS protocol)進(jìn)行通信。DNS協(xié)議主要基于UDP，是應(yīng)用層協(xié)議。
在整個(gè)DNS查詢過程中，無論是重新定向還是最終取得對(duì)應(yīng)關(guān)系，都是用戶計(jì)算機(jī)和DNS服務(wù)器使用DNS協(xié)議通信。用戶計(jì)算機(jī)根據(jù)DNS服務(wù)器的反饋，依次與下一層的DNS服務(wù)器建立通信。用戶計(jì)算機(jī)經(jīng)過遞歸查詢，最終和末端節(jié)點(diǎn)通信，并獲得IP地址。
DNS Resolver（域名解析模塊）通常有DNS緩存(cache)，用來記錄最近使用和查詢的域名/IP關(guān)系。在進(jìn)行DNS查詢之前，計(jì)算機(jī)會(huì)先查詢cache中是否有相關(guān)記錄。這樣，重復(fù)使用的域名就不用總要經(jīng)過整個(gè)遞歸查詢過程。

4.2 HTTP

HTTP協(xié)議解決文件傳輸?shù)膯栴}。HTTP是應(yīng)用層協(xié)議，主要建立在TCP協(xié)議之上(偶爾也可以UDP為底層)。它隨著萬維網(wǎng)的發(fā)展而流行。HTTP協(xié)議目的是，如何在萬維網(wǎng)的網(wǎng)絡(luò)環(huán)境下，更好的利用TCP協(xié)議，以實(shí)現(xiàn)文件，特別是超文本文件的傳輸。

早期的HTTP協(xié)議主要傳輸靜態(tài)文件，即真實(shí)存儲(chǔ)在服務(wù)器上的文件。隨著萬維網(wǎng)的發(fā)展，HTTP協(xié)議被用于傳輸“動(dòng)態(tài)文件”，服務(wù)器上的程序根據(jù)HTTP請(qǐng)求即時(shí)生成的動(dòng)態(tài)文件。我們將HTTP的傳輸對(duì)象統(tǒng)稱為資源(resource)。

兩個(gè)過程： 請(qǐng)求（request）回復(fù)（response）

格式：

起始行 (start line)
頭信息 (headers)

主體(entity body)

起始行只有一行。它包含了請(qǐng)求/回復(fù)最重要的信息。請(qǐng)求的起始行表示(顧客)“想要什么”。回復(fù)的起始行表示(后廚)“發(fā)生什么”。
頭信息可以有多行。每一行是一對(duì)鍵值對(duì)(key-value pair)

早期的HTTP協(xié)議只有GET方法。遵從HTTP協(xié)議，服務(wù)器接收到GET請(qǐng)求后，會(huì)將特定資源傳送給客戶。
GET方法也可以用于傳輸一些不重要的數(shù)據(jù)。它是通過改寫URL的方式實(shí)現(xiàn)的。GET的數(shù)據(jù)利用URL?變量名＝變量值的方法傳輸。比如向http://127.0.0.1發(fā)送一個(gè)變量“q”，它的值為“a”。那么，實(shí)際的URL為http://127.0.0.1?q=a。服務(wù)器收到請(qǐng)求后，就可以知道"q"的值為"a"。

POST方法用于從客戶端向服務(wù)器提交數(shù)據(jù)。使用POST方法時(shí)，URL不再被改寫。數(shù)據(jù)位于http請(qǐng)求的主體。POST方法最用于提交HTML的form數(shù)據(jù)。服務(wù)器往往會(huì)對(duì)POST方法提交的數(shù)據(jù)進(jìn)行一定的處理，比如存入服務(wù)器數(shù)據(jù)庫(kù)。

HTTP協(xié)議的默認(rèn)端口是80

狀態(tài)碼：200, OK; 302，重新定向(redirect); 404，無法找到(not found)

4.3 DHCP協(xié)議用于動(dòng)態(tài)的配置電腦的網(wǎng)絡(luò)相關(guān)參數(shù)，如主機(jī)的IP地址，路由器出口地址、DNS域名服務(wù)器地址等。一臺(tái)電腦只要接上網(wǎng)，就可以通過DHCP協(xié)議獲得相關(guān)配置，從而順利的暢游網(wǎng)絡(luò)。

DHCP協(xié)議全稱為“動(dòng)態(tài)主機(jī)設(shè)置協(xié)議”（Dynamic Host Configuration Protocol）。通常來說，普通電腦中都內(nèi)置有DHCP客戶端模塊。電腦接上網(wǎng)絡(luò)后，DHCP客戶端發(fā)現(xiàn)新連通的網(wǎng)絡(luò)，會(huì)在該網(wǎng)絡(luò)上找DHCP服務(wù)器。DHCP服務(wù)器將給電腦提供合理的網(wǎng)絡(luò)配置，并把設(shè)置信息傳回本機(jī)。所謂的DHCP服務(wù)器，其實(shí)就是一些運(yùn)行有DHCP服務(wù)器端軟件的特殊電腦。他們像等候在網(wǎng)絡(luò)上的服務(wù)員，為新來的顧客排憂解難。本機(jī)和DHCP服務(wù)器之間的通信，都是通過DHCP協(xié)議進(jìn)行的。
DHCP協(xié)議的底層是UDP協(xié)議。

DHCP通信分為四步：

1. Discovery：客戶機(jī)發(fā)廣播，搜尋DHCP服務(wù)器。
2. Offer：DHCP服務(wù)器發(fā)出邀請(qǐng)，提供一個(gè)可用的IP地址。
3. Request：客戶機(jī)正式請(qǐng)求使用該IP地址。
4. Acknowledge：DHCP服務(wù)器確認(rèn)，并提供其他配置參數(shù)。