運輸層和TCP/IP協(xié)議

0. 基本要點

  • 運輸層是為相互通信的應(yīng)用進(jìn)程提供邏輯通信巩那。
  • 端口和套接字的意義
  • 什么是無連接UDP
  • 什么是面向連接的TCP
  • 在不可靠的網(wǎng)絡(luò)上實現(xiàn)可靠傳輸?shù)墓ぷ髟?/strong>跳夭,停止等待協(xié)議和ARQ協(xié)議
  • TCP的滑動窗口、流量控制涡戳、擁塞控制和連接管理

1. 運輸層協(xié)議概述

  • 為什么需要運輸層哭尝?
    通信真正的端點并不是主機而是主機中的進(jìn)程驹吮,IP協(xié)議幫助我們將分組數(shù)據(jù)發(fā)送到對應(yīng)的主機茸时,但是這個分組還是停留在了網(wǎng)絡(luò)層,IP協(xié)議并不知道需要將分組數(shù)據(jù)交付給主機中的哪一個應(yīng)用或者哪一個進(jìn)程赋访,而運輸層的作用在于可都,一方面為上層應(yīng)用層提供進(jìn)程的端到端通信服務(wù),一方面屏蔽了下面網(wǎng)絡(luò)核心的細(xì)節(jié)蚓耽,在邏輯上好像兩個進(jìn)程實體之間存在一條端到端的邏輯通信通道渠牲。
  • 運輸層的兩個功能:復(fù)用和分用
運輸層.PNG
  • 運輸層和網(wǎng)絡(luò)層的區(qū)別:
    1. 網(wǎng)絡(luò)層為主機之間提供邏輯通信步悠,運輸層為進(jìn)程之間提供端到端的邏輯通信
    2. 運輸層還要對報文進(jìn)行差錯檢測签杈,網(wǎng)絡(luò)層只檢驗頭部部分

2. TCP和UDP

  • UDP傳輸?shù)氖荱DP報文段答姥,在傳送數(shù)據(jù)之前不需要建立連接
  • TCP提供面向連接的服務(wù),傳送數(shù)據(jù)前要建立連接,傳送結(jié)束后要釋放連接祈噪,TCP 不提供廣播和多播服務(wù)杠茬,因為TCP要保證可靠的連接遂填,因此增加很多相應(yīng)的開銷铲觉,協(xié)議首部會相對較大,同時也占用很多處理機的資源
應(yīng)用 應(yīng)用層協(xié)議 運輸層協(xié)議
名字轉(zhuǎn)換 DNS(域名系統(tǒng)) UDP
文件傳輸 TFIP(簡單文件傳輸協(xié)議) UDP
路由選擇協(xié)議 RIP(路由協(xié)議信息) UDP
IP地址分配 DHCP(動態(tài)主機配置地址) UDP
網(wǎng)絡(luò)管理 SNMP(簡單網(wǎng)絡(luò)管理協(xié)議) UDP
遠(yuǎn)程文件服務(wù)器 NFS(網(wǎng)絡(luò)文件系統(tǒng)) UDP
IP電話 專用協(xié)議 UDP
流式多媒體通信 專用協(xié)議 UDP
多播 IGMP(網(wǎng)際組管理協(xié)議) UDP
電子郵件 SMTP(簡單郵件傳輸協(xié)議) TCP
遠(yuǎn)程終端接入 TElNET(遠(yuǎn)程終端協(xié)議) TCP
萬維網(wǎng) HTTP(超文本傳輸) TCP
文件傳輸 FTP(文件傳輸協(xié)議) TCP
  • 端口:標(biāo)志本計算機應(yīng)用層的各個進(jìn)程與運輸層交互的層間接口吓坚,為了找到對方計算機中的應(yīng)用進(jìn)程撵幽。因為進(jìn)程在不同的操作系統(tǒng)中的進(jìn)程標(biāo)識符是不同的,因此用標(biāo)識符來識別進(jìn)程是行不通的礁击。
    1. 服務(wù)器使用的端口號:系統(tǒng)端口號:0-1023 登記端口號:1024-49151
      常見端口號:FTP:21盐杂, TELNET:23, SMTP:25
      DNS:55哆窿,TFTP:69链烈,HTTP:80
      SNMP:161 SMP(trap):162 ,HTTPS:443

    2. 客戶端使用端口號:短暫端口號 49152-65535

3. UDP協(xié)議

  • UDP是無連接的挚躯,UDP不需要維持復(fù)雜的連接狀態(tài)表强衡,它盡最大努力交付
  • UDP是面向報文的,這里注意:UDP對于應(yīng)用層交下來的報文码荔,既不合并漩勤,也不拆分,而是保留這些報文的邊界缩搅,應(yīng)用層交給UDP多長的報文越败,UDP就封裝多長的報文,因此硼瓣,用戶需要選擇合適的報文長度究飞,否則交給IP層后,過長會導(dǎo)致分片堂鲤,太短會造成首部相對長度太大亿傅,降低IP層的效率。
  • UDP沒有擁塞控制瘟栖,網(wǎng)絡(luò)擁塞不會降低源主機的發(fā)送效率袱蜡。在一些實時應(yīng)用中,如IP電話允許存在一定程度的丟包慢宗,但不允許太大延時坪蚁。
  • UDP支持一對一,一對多镜沽,多對多交互通信
  • UDP首部開銷小敏晤,只有8個字節(jié),每個字段的長度都是兩個字節(jié)缅茉,源端口+目的端口+長度+校驗和

4. TCP協(xié)議

4.1 TCP協(xié)議特點

  • TCP協(xié)議是面向連接的嘴脾,使用時建立連接,使用完畢釋放連接
  • 每個TCP連接只有連個端點,也就是說TCP連接是點對點译打,一對一的
  • TCP提供可靠的交付耗拓,無差錯,不丟失奏司,不重復(fù)乔询,并且按序到達(dá)
  • TCP提供全雙工的通信,TCP允許進(jìn)程任何時候都發(fā)送數(shù)據(jù)韵洋,TCP兩端設(shè)有發(fā)送緩存和接收緩存竿刁,TCP會在合適的時候讀取緩存或者將緩存中的數(shù)據(jù)發(fā)送出去。
  • TCP面向字節(jié)流搪缨,注意TCP并不關(guān)心進(jìn)程一次將多少緩存發(fā)送到TCP的緩存食拜,UPD發(fā)送的報文長度由進(jìn)程指定,而TCP則是根據(jù)對方給的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞情況而決定一個報文段包含多少字節(jié)副编。如果緩存數(shù)據(jù)塊過長负甸,TCP劃分短一些,過短就積累足夠多的字節(jié)構(gòu)成報文段發(fā)送出去痹届。

4.2 套接字

  • 套接字是一個抽象的概念:socket = (IP地址:端口號)呻待,TCP連接:{套接字}:{套接字},同一個IP地址可以有多個不同的TCP連接短纵,同一個端口號也可以出現(xiàn)在多個不同的TCP連接中带污。

4.3 可靠傳輸?shù)墓ぷ髟?/h4>

基本原理:當(dāng)出現(xiàn)差錯時讓發(fā)送方重新傳輸出錯的數(shù)據(jù)僵控,同時在收方來不及處理數(shù)據(jù)時香到,及時告知發(fā)送方降低發(fā)送速率。

  • 停止等待協(xié)議(最簡單的協(xié)議报破,實際運輸層并沒有采用):發(fā)送完一個分組后停止發(fā)送悠就,等待對方的確認(rèn),收到確認(rèn)后再發(fā)送下一個分組充易,如果收不到對方確認(rèn)梗脾,超時重傳,而產(chǎn)生超時重傳的原因可能是收方的確認(rèn)丟失了盹靴,也可能是發(fā)送方發(fā)送的分組出錯或者丟失炸茧,因此對于收方,對于重傳的分組稿静,假如是已經(jīng)收到過的分組梭冠,此時需要執(zhí)行丟棄重復(fù)分組,向發(fā)送方發(fā)送確認(rèn)的動作改备。對于可能遲到的確認(rèn)控漠,發(fā)送方執(zhí)行收下丟棄的處理。這種自動重傳的協(xié)議我們稱之為ARQ(Automatic Repeat request)協(xié)議
  • ARQ協(xié)議最大的缺點是信道利用率太低盐捷,要一直等待來回往返的確認(rèn)RTT時間偶翅,如果往返時間大于分組發(fā)送時間Td,那么信道利用率是非常低的碉渡。因此未來提高傳輸效率聚谁,采用流水線發(fā)送,也就是連續(xù)ARQ協(xié)議和滑動窗口協(xié)議爆价。
  • 連續(xù)ARQ協(xié)議與go-back-N

4.4 TCP報文段首部

TCP頭部.PNG

有幾個比較重要的概念:

  • 序號:占4個字節(jié)垦巴,一個TCP連接中的傳輸?shù)淖止?jié)流都要按順序編號,比如一個報文字節(jié)序號為301铭段,攜帶100個字節(jié)數(shù)據(jù)骤宣,那么該報文中第一個字節(jié)的序號為301,最后一個字節(jié)為400序愚,下一個報文的序號字段值應(yīng)為401
  • 確認(rèn)號:占4個字節(jié)憔披,是期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號。比如B正確收到了A發(fā)來的501-700的數(shù)據(jù)爸吮,那么B發(fā)送給A的確認(rèn)報文中確認(rèn)號位701芬膝,確認(rèn)號=N,則表明到序號N-1為止所有數(shù)據(jù)都正確收到形娇。
  • 窗口:窗口值告訴對方從本報文首部確認(rèn)號算起锰霜,接收方目前允許對方發(fā)送的數(shù)據(jù)量,(接收方的緩存是有限的)桐早。B返回給A確認(rèn)號701癣缅,窗口字段為1000,也就是告訴對方哄酝,從701開始友存,我的接收緩存空間還可接收1000個字節(jié)數(shù)據(jù),你在發(fā)送數(shù)據(jù)時陶衅,必須考慮這一點屡立。窗口字段明確指出現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量,窗口值經(jīng)常在動態(tài)變化搀军。
  • 選項:最大報文段長度MSS膨俐,窗口擴大項,時間戳(可處理**TCP序號超過2^32的情況罩句,防止序號繞回)

5. TCP的可靠傳輸?shù)膶崿F(xiàn)

TCP 滑動窗口協(xié)議

以字節(jié)為單位的滑動窗口:發(fā)送方A的發(fā)送窗口焚刺,接收方B的接收窗口

  • 發(fā)送方緩存:發(fā)送緩存用于存放準(zhǔn)備發(fā)送的數(shù)據(jù)和已經(jīng)發(fā)送但尚未收到確認(rèn)的數(shù)據(jù)
  • 發(fā)送窗口:發(fā)送窗口是發(fā)送緩存的一部分,已經(jīng)確認(rèn)的數(shù)據(jù)應(yīng)當(dāng)從發(fā)送緩存中刪除的止,因此發(fā)送緩存和發(fā)送窗口的后沿是重合的(注意發(fā)送程序需要控制寫入緩存的速率檩坚,太快會導(dǎo)致緩存沒有存放數(shù)據(jù)的空間,因為發(fā)送的數(shù)據(jù)可能還未被確認(rèn))
  • 接收緩存存放:按序到達(dá)但還沒有被應(yīng)用接收的數(shù)據(jù)和未按序到達(dá)的數(shù)據(jù)
  • 接收窗口:如果收到分組出錯,就要丟棄匾委,如果接收應(yīng)用程序來不及接收數(shù)據(jù)拖叙,接收緩存會被填滿,接收窗口會被減小為零赂乐,如果能夠及時處理薯鳍,接收窗口就可以增大,接收窗口動態(tài)調(diào)整挨措,并反饋給發(fā)送方挖滤,以通知發(fā)送方調(diào)整發(fā)送速率
  • 發(fā)送窗口兩個決定因素:1.B的接收窗口作為參考 2.根據(jù)網(wǎng)絡(luò)擁塞情況適當(dāng)減小發(fā)送窗口數(shù)值
  • 整個發(fā)送過程可以描述為:
    1. A可以將窗口內(nèi)的數(shù)據(jù)都發(fā)送出去浅役,在此期間不需要收到B的確認(rèn)情況斩松,凡是沒有得到確認(rèn)的已發(fā)送數(shù)據(jù)暫時保留,以便超時重傳觉既。
    2. B接收窗口對按序收到的數(shù)據(jù)的最高序號給出確認(rèn)惧盹,如果B確認(rèn)收到這些數(shù)據(jù),就將接收窗口向前移動瞪讼,并給A發(fā)送確認(rèn)钧椰,A收到確認(rèn)后,就將發(fā)送窗口向前移動符欠。
    3. 如果A一直發(fā)送數(shù)據(jù)嫡霞,一直到整個發(fā)送窗口內(nèi)的數(shù)據(jù)發(fā)送完畢,也沒有收到B的確認(rèn)希柿,那么A的發(fā)送窗口已滿诊沪,則需要停止發(fā)送,經(jīng)過一段時間(超時)重傳這部分?jǐn)?shù)據(jù)狡汉,直到收到B的確認(rèn)娄徊,就可以向前移動窗口了闽颇。
  • 超時重傳的時間選擇
    1. 過短盾戴,引起不必要的重傳,過長兵多,空閑時間增大尖啡,降低效率
    2. 自適應(yīng)算法,記錄報文段往返時間RTT(報文發(fā)出到收到確認(rèn)之間的時間)剩膘,通過測量RTT衅斩,獲得一個加權(quán)平均往返時間RTTs
      新RTTs = (1-α)*舊RTTs + α * 新RTT樣本(α通常為0.125)
      則超時重傳時間RTO為:RTO= RTTs + 4 * RTTd(RTT的偏差加權(quán)平均值)
    3. Kam算法:在計算加權(quán)平均RTTs的時候,只要報文段重傳了怠褐,就不采用其往返時間樣本畏梆。

6. TCP的流量控制

注意理解流量控制和擁塞控制的區(qū)別

  • 流量控制:flow control,讓發(fā)送方發(fā)送速率不要太快,要讓接收方來得及接收奠涌,也就是說是一對一宪巨,發(fā)送方和接收方的協(xié)商
  • 流量控制的實現(xiàn):滑動窗口機制,發(fā)送方的接收窗口不能超過接收方的接收窗口溜畅,接收方在發(fā)送ACK時可向發(fā)送方發(fā)送rwnd字段捏卓,告知接收窗口的大小進(jìn)行流量控制
流量控制.PNG
  • 注意死鎖的產(chǎn)生:B向A發(fā)送了零窗口報文后,過一段時間后B有了空間并向A發(fā)送rwnd = n的報文段慈格,但是該報文段丟失了怠晴,這個時候A在等待B,B也在等待A重新發(fā)送數(shù)據(jù)浴捆,導(dǎo)致了互相等待的死鎖局面蒜田。解決方法是當(dāng)TCP連接的一方接到對方的零窗口通知,就啟動持續(xù)計時器选泻,如果時間到物邑,就發(fā)送一個零窗口探測報文段
  • TCP傳輸效率:控制TCP發(fā)送報文段的時機
    1. Nagle算法:Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)滔金,避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊色解。Nagle算法的基本定義是任意時刻,最多只能有一個未被確認(rèn)的小段餐茵。 所謂“小段”科阎,指的是小于MSS尺寸的數(shù)據(jù)塊,所謂“未被確認(rèn)”忿族,是指一個數(shù)據(jù)塊發(fā)送出去后锣笨,沒有收到對方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。

    (1)如果包長度達(dá)到MSS或者發(fā)送窗口大小的一半道批,則允許發(fā)送错英;
    (2)如果該包含有FIN隆豹,則允許發(fā)送椭岩;
    (3)設(shè)置了TCP_NODELAY選項,則允許發(fā)送璃赡;
    (4)未設(shè)置TCP_CORK選項時判哥,若所有發(fā)出去的小數(shù)據(jù)包(包長度小于MSS)均被確認(rèn),則允許發(fā)送碉考;
    (5)上述條件都未滿足塌计,但發(fā)生了超時(一般為200ms),則立即發(fā)送侯谁。

    1. 糊涂窗口綜合征(silly window syndrome)

7. TCP的擁塞控制

7.1 擁塞控制與流量控制的區(qū)別

  • 擁塞產(chǎn)生的原因:對網(wǎng)絡(luò)資源的需求大于可用的資源锌仅,可能是帶寬不夠章钾,也可能是交換結(jié)點的緩存太小,也可能是發(fā)送方發(fā)送數(shù)據(jù)過快热芹,而接受方接受數(shù)據(jù)過慢
  • 擁塞控制:擁塞控制是防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中伍玖,這樣使得網(wǎng)絡(luò)中路由器或者鏈路不至于過載,擁塞控制是一個全局性控制剿吻,涉及到所有主機窍箍、所有路由器以及降低網(wǎng)絡(luò)傳輸性能有關(guān)的因素,相對于流量控制丽旅,流量控制是點對點通信量的控制椰棘,是一個端到端的問題,抑制發(fā)送端發(fā)送速率榄笙,以便接收端來得及接收邪狞。
  • 擁塞控制容易與流量控制搞混,實際上某些擁塞控制就是通過向發(fā)送端報告網(wǎng)絡(luò)情況茅撞,減緩發(fā)送速率來實現(xiàn)擁塞的控制
  • 擁塞控制由開環(huán)控制和閉環(huán)控制兩種方法:
    1. 開環(huán):設(shè)計網(wǎng)絡(luò)時充分考慮有關(guān)擁塞情況帆卓,力求網(wǎng)絡(luò)工作時不發(fā)送擁塞
    2. 閉環(huán):檢測系統(tǒng)網(wǎng)絡(luò)以便檢測擁塞在何處發(fā)生何時發(fā)生,然后根據(jù)擁塞產(chǎn)生的信息來調(diào)整網(wǎng)絡(luò)運行狀態(tài)米丘,調(diào)整狀態(tài)的操作如增大網(wǎng)絡(luò)某些可用資源剑令,或減少用戶對某些資源的額需求等,調(diào)整過程也是一個動態(tài)變化的過程

7.2 TCP擁塞控制方法

TCP擁塞控制算法包括:慢開始(Slow-start)拄查,擁塞避免(congestion avoidance),快重傳(fast retransmit)和快恢復(fù)(fast recovery),這四個算法是配合起來使用的吁津,以實現(xiàn)擁塞控制,當(dāng)然這里的擁塞控制本質(zhì)上是流量控制

擁塞控制.PNG
  • 判斷網(wǎng)絡(luò)擁塞的依據(jù):出現(xiàn)超時

  • 慢開始:當(dāng)主機開始發(fā)送數(shù)據(jù)時堕扶,并不清楚網(wǎng)絡(luò)的負(fù)載情況碍脏,如果將大量字節(jié)注入網(wǎng)絡(luò)卦方,有可能引起網(wǎng)絡(luò)擁塞准潭,那么可以先探測一下,由小到大逐漸增大擁塞窗口數(shù)值惩阶,也就是逐漸增大發(fā)送窗口糊探。初始擁塞窗口cwnd設(shè)置不超過2-4個SMSS(sender maximum segement size)

    1. 慢開始規(guī)定钾埂,每收到一個對新的報文段的確認(rèn)后,就可以將擁塞窗口增加最多一個SMSS數(shù)值侧到,也就是每次增加量 = min(N,SMSS)勃教,N是原先未確認(rèn)淤击,但是現(xiàn)在剛收到確認(rèn)的字節(jié)數(shù)
    2. 如圖所示匠抗,每經(jīng)過一個傳輸輪次,擁塞窗口cwnd就加倍污抬,(傳輸輪次是指往返時間RTT汞贸,就是將發(fā)送窗口中所有數(shù)據(jù)都發(fā)送出去了绳军,并且發(fā)送方收到了對該窗口中最后一個字節(jié)的確認(rèn)的這樣一個輪次)
    3. 慢開始的慢在于TCP剛開始發(fā)送時是一個試探性發(fā)送的狀態(tài),其窗口cwnd的增長速率并不慢矢腻,是呈指數(shù)增長的门驾。
  • 擁塞避免:因為慢開始的增長速率很快,cwnd很快就變得很大多柑,如果增長過快就會產(chǎn)生網(wǎng)絡(luò)擁塞奶是,所以需要一個慢開始門限。在cwnd達(dá)到門限之后竣灌,采用擁塞避免算法聂沙,使得cwnd緩慢線性增長

    1. cwnd<ssthresh,使用慢開始算法初嘹,cwnd>ssthresh,使用擁塞避免及汉,cwnd = ssthresh,兩者皆可
    2. 擁塞避免每經(jīng)過一個RTT時間屯烦,將cwnd加1坷随,也就是加法增大,線性規(guī)律增長驻龟;
    3. 如果當(dāng)達(dá)到某一窗口大小温眉,產(chǎn)生超時,發(fā)送方判斷為擁塞產(chǎn)生翁狐,則**調(diào)整門限值ssthresh = cwnd(當(dāng)前值)/2, cwnd = 1(調(diào)整為1芍殖,進(jìn)入慢開始)
  • 快重傳:目的是當(dāng)網(wǎng)絡(luò)沒有產(chǎn)生擁塞,但是出現(xiàn)個別報文段丟失谴蔑,為了避免發(fā)送方認(rèn)為超時進(jìn)入慢開始狀態(tài)豌骏,應(yīng)盡快在超時的限制時間內(nèi)讓發(fā)送方盡早知道有個別報文段產(chǎn)生了丟失,以盡快進(jìn)行重傳隐锭,這樣就不會產(chǎn)生超時窃躲,不會被默認(rèn)為存在網(wǎng)絡(luò)擁塞。

    1. 快重傳算法要求立即確認(rèn)钦睡,要求接受方不使用捎帶確認(rèn)蒂窒,而是即使收到了失序報文段也要立即發(fā)出對已收到報文段的額重復(fù)確認(rèn)
    2. 算法規(guī)定荞怒,只要連續(xù)收到3個重復(fù)確認(rèn)洒琢,就知道是哪一段對方?jīng)]有收到,應(yīng)道立即進(jìn)行重傳
  • 快恢復(fù):承接快重傳褐桌,發(fā)送方知道已經(jīng)丟失了個別報文段衰抑,執(zhí)行快回復(fù)算法調(diào)整門限ssthresh = cwnd /2,設(shè)置cwnd = ssthresh荧嵌,并開始執(zhí)行擁塞避免算法呛踊,也有將ssthresh = cwnd/2 +3

    TCP擁塞控制流程圖.PNG
  • 注意:發(fā)送方窗口是由網(wǎng)絡(luò)擁塞情況和對方的接收窗口共同決定的
    發(fā)送窗口上限值 = Min{rwnd砾淌,cwnd}

  • 主動隊列管理:AQM(active queue management),路由器內(nèi)部隊列采用先入先出規(guī)則谭网,如果隊列已滿汪厨,會丟棄再到達(dá)的分組,如果被動的隊滿丟棄愉择,容易影響很多TCP連接劫乱,導(dǎo)致全局同步,全局通信量下降锥涕,所以采用主動隊列管理要拂,當(dāng)網(wǎng)絡(luò)擁塞出現(xiàn)某些征兆的時候,主動丟棄某些分組站楚,隨機早期檢測就是當(dāng)隊列平均隊列長度達(dá)到一定值時脱惰,按照某種概率丟棄個別分組,這樣讓擁塞控制只在某些TCP連接上出現(xiàn)窿春。

8. TCP連接建立拉一,數(shù)據(jù)傳輸和連接釋放

  • TCP采用C/S模型,主動發(fā)起連接的是客戶旧乞,等待連接的是服務(wù)器
三報文握手.PNG
  • A和B都各自選擇初始序列號 x蔚润,y
  • SYN = 1 即SYN報文段不能攜帶數(shù)據(jù),但要消耗一個序號
  • ACK報文段可以攜帶數(shù)據(jù)尺栖,如果不攜帶數(shù)據(jù)就不消耗序號
  • 為什么A最后還要再發(fā)送一個ACK嫡纠?是為了防止已經(jīng)失效連接報文請求突然傳送到B,因而產(chǎn)生錯誤
TCP連接釋放.PNG
  • B結(jié)束TCP連接的時間要早于A
  • 當(dāng)A處于FIN-WAIT-2狀態(tài)時延赌,TCP處于半關(guān)閉狀態(tài)除盏,也就是說這個時候A已經(jīng)不需要發(fā)送數(shù)據(jù)給B了,但是如果B有數(shù)據(jù)想要發(fā)送挫以,A仍然需要接收
  • A接收到B釋放連接報文并返回ACK后處于TIME-WAIT狀態(tài)者蠕,還要等待2MSL才可以釋放連接
    1. 實現(xiàn)終止TCP全雙工連接的可靠性:假設(shè)最后的ACK丟失,服務(wù)器會重發(fā)FIN掐松,因此客戶端需要維護狀態(tài)信息以允許重發(fā)最終的ACK(對于主動斷開連接的服務(wù)器是同樣的道理)保證A發(fā)送的最后一個ACK報文段能夠到達(dá)B
    2. 保證老的重復(fù)分節(jié)在網(wǎng)絡(luò)消失:保證來自先前連接的老的重復(fù)分組已經(jīng)消失踱侣,2MSL(maximum segment lifetime 最長分節(jié)生命)時間足夠讓某個方向上的分組丟棄
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市大磺,隨后出現(xiàn)的幾起案子抡句,更是在濱河造成了極大的恐慌,老刑警劉巖杠愧,帶你破解...
    沈念sama閱讀 211,290評論 6 491
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件待榔,死亡現(xiàn)場離奇詭異,居然都是意外死亡殴蹄,警方通過查閱死者的電腦和手機究抓,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,107評論 2 385
  • 文/潘曉璐 我一進(jìn)店門猾担,熙熙樓的掌柜王于貴愁眉苦臉地迎上來袭灯,“玉大人刺下,你說我怎么就攤上這事』” “怎么了橘茉?”我有些...
    開封第一講書人閱讀 156,872評論 0 347
  • 文/不壞的土叔 我叫張陵,是天一觀的道長姨丈。 經(jīng)常有香客問我畅卓,道長,這世上最難降的妖魔是什么蟋恬? 我笑而不...
    開封第一講書人閱讀 56,415評論 1 283
  • 正文 為了忘掉前任翁潘,我火速辦了婚禮,結(jié)果婚禮上歼争,老公的妹妹穿的比我還像新娘拜马。我一直安慰自己,他們只是感情好沐绒,可當(dāng)我...
    茶點故事閱讀 65,453評論 6 385
  • 文/花漫 我一把揭開白布俩莽。 她就那樣靜靜地躺著,像睡著了一般乔遮。 火紅的嫁衣襯著肌膚如雪扮超。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,784評論 1 290
  • 那天蹋肮,我揣著相機與錄音出刷,去河邊找鬼。 笑死坯辩,一個胖子當(dāng)著我的面吹牛巷蚪,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播濒翻,決...
    沈念sama閱讀 38,927評論 3 406
  • 文/蒼蘭香墨 我猛地睜開眼屁柏,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了有送?” 一聲冷哼從身側(cè)響起淌喻,我...
    開封第一講書人閱讀 37,691評論 0 266
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎雀摘,沒想到半個月后裸删,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 44,137評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡阵赠,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,472評論 2 326
  • 正文 我和宋清朗相戀三年涯塔,在試婚紗的時候發(fā)現(xiàn)自己被綠了肌稻。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,622評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡匕荸,死狀恐怖爹谭,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情榛搔,我是刑警寧澤诺凡,帶...
    沈念sama閱讀 34,289評論 4 329
  • 正文 年R本政府宣布,位于F島的核電站践惑,受9級特大地震影響腹泌,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜尔觉,卻給世界環(huán)境...
    茶點故事閱讀 39,887評論 3 312
  • 文/蒙蒙 一凉袱、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧侦铜,春花似錦专甩、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,741評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至嫁盲,卻和暖如春篓叶,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背羞秤。 一陣腳步聲響...
    開封第一講書人閱讀 31,977評論 1 265
  • 我被黑心中介騙來泰國打工缸托, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人瘾蛋。 一個月前我還...
    沈念sama閱讀 46,316評論 2 360
  • 正文 我出身青樓俐镐,卻偏偏與公主長得像,于是被迫代替她去往敵國和親哺哼。 傳聞我的和親對象是個殘疾皇子佩抹,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,490評論 2 348

推薦閱讀更多精彩內(nèi)容

  • 六、TCP可靠傳輸?shù)膶崿F(xiàn) 首先介紹以字節(jié)為單位的滑動窗口取董。為了講述可靠傳輸原理的方便棍苹,假定數(shù)據(jù)傳輸只在一個方向進(jìn)行...
    dmmy大印閱讀 1,671評論 0 1
  • 1.這篇文章不是本人原創(chuàng)的,只是個人為了對這部分知識做一個整理和系統(tǒng)的輸出而編輯成的茵汰,在此鄭重地向本文所引用文章的...
    SOMCENT閱讀 13,049評論 6 174
  • 個人認(rèn)為枢里,Goodboy1881先生的TCP /IP 協(xié)議詳解學(xué)習(xí)博客系列博客是一部非常精彩的學(xué)習(xí)筆記,這雖然只是...
    貳零壹柒_fc10閱讀 5,051評論 0 8
  • 本書結(jié)構(gòu)是自頂向下的,所以請按下列順序閱讀: 1.計算機網(wǎng)絡(luò)自頂向下--應(yīng)用層2.計算機網(wǎng)絡(luò)自頂向下--運輸層3....
    牛富貴兒閱讀 2,729評論 0 3
  • 傳輸層-TCP栏豺, TCP頭部結(jié)構(gòu) 彬碱,TCP序列號和確認(rèn)號詳解 TCP主要解決下面的三個問題 1.數(shù)據(jù)的可靠傳輸...
    抓兔子的貓閱讀 4,512評論 1 46