TCP連接

持續(xù)連接

缺點(diǎn)

• 可能會(huì)損害服務(wù)器的整體性能
• 需要很多探測(cè)包來(lái)維持這個(gè)連接

優(yōu)點(diǎn)

• 減少CPU以及內(nèi)存的使用
• 發(fā)生錯(cuò)誤時(shí)，可以在不關(guān)閉連接的情況下進(jìn)行提示
• 減少網(wǎng)絡(luò)堵塞，減少了TCP請(qǐng)求

非持續(xù)連接

缺點(diǎn)

• 對(duì)于每個(gè)這樣的連接，在客戶和服務(wù)器巾都要分配 TCP 的緩沖區(qū)和保持 TCP 變量. 這給 Web 服務(wù)器帶來(lái)了嚴(yán)重的負(fù)擔(dān)，因?yàn)橐慌_(tái) Web 服務(wù)器可能同時(shí)服務(wù)于數(shù)以百計(jì)不同 的客戶的請(qǐng)求。

優(yōu)點(diǎn)

• 其中每個(gè) TCP 連接在服務(wù)器發(fā)送一個(gè)對(duì)象后 關(guān)閉， 該連接并不為其他的對(duì)象而持續(xù)下來(lái)。 值得注意的是每個(gè) TCP 連接只傳輸一個(gè)請(qǐng)求 報(bào)文和一個(gè)響應(yīng)報(bào)文。

HTTP響應(yīng)報(bào)文

http服務(wù)器是無(wú)狀態(tài)的，這簡(jiǎn)化了服務(wù)器的設(shè)計(jì)，并且允許工程師 們?nèi)ラ_(kāi)發(fā)可以同時(shí)處理數(shù)以千計(jì)的 TCP 連接的高性能 Web 服務(wù)器。

一個(gè)初始狀態(tài)行

• 協(xié)議版本字段
• 狀態(tài)碼
• 相應(yīng)狀態(tài)信息

六個(gè)首部行

• 服務(wù)器用 Connection: close 首部行告訴客戶，發(fā)送完報(bào)文后 將關(guān)閉該 TCP 連接。
• Server: 首部行指示該報(bào)文 是由一臺(tái) Apache Web 服務(wù)器產(chǎn)生的.它類似于 HTTP 請(qǐng)求報(bào)文中的 User-agent
• Date: 首部行指示服務(wù)器產(chǎn)生并發(fā)送該響應(yīng)報(bào)文的日期和時(shí)間。
• Lasl-Modified: 首部行 對(duì)既可能在本地客戶也可能在網(wǎng)絡(luò)緩存服務(wù)器上的對(duì)象緩存來(lái)說(shuō)非常重要。
• Conlenl-Length: 首部行指示了被發(fā)送對(duì)象中的 字節(jié)數(shù)。
• Conlent-Type: 首部行指示了實(shí)體體中的對(duì)象是 HTML 文本

空行

實(shí)體體

cookie

在 HTTP 響應(yīng)報(bào)文中的一個(gè) cookie 首部 行

在 HTTP 請(qǐng)求報(bào)文中的一個(gè) cookie 首部行

在用戶端系統(tǒng)中保留有一個(gè) cookie 文 件，并由用戶的瀏覽器進(jìn)行管理

位于 Web 站點(diǎn)的一個(gè)后端數(shù)據(jù)庫(kù)

web緩存

它是能夠代表 初始 Web 服務(wù)器來(lái)滿足 HTTP 請(qǐng)求的網(wǎng)絡(luò)實(shí)體

是服務(wù)器又是客戶

Web 緩存器能夠大大減少一個(gè)機(jī)構(gòu)的接入鏈路到因特網(wǎng)的通信量

內(nèi)容分發(fā)網(wǎng)絡(luò)CDN

• CDN公司在因特網(wǎng)上安裝了許多地理上分散的緩 存器，因而使大量流量實(shí)現(xiàn)了本地化。

可能存在的問(wèn)題：存放在緩存器中的對(duì)象副本可能是陳舊的，保存在服務(wù)器中的對(duì)象自該副本緩存在客戶上以后可能已經(jīng)被修改了

條件GET方法

請(qǐng)求報(bào)文使用 GET 方法

請(qǐng)求報(bào)文中包 含一個(gè)"If-Modified -Since : "首部行

該 Web 服務(wù)器仍發(fā)送一個(gè)響應(yīng)報(bào)文，但 并沒(méi)有在該響應(yīng)報(bào)文中包含所請(qǐng)求的對(duì)象。

FTP協(xié)議

FTP 使用了兩個(gè)并 行的 TCP 連接來(lái)傳輸文件， 一個(gè)是控制連接 (control connection) ，一個(gè)是數(shù)據(jù)連接( data connection)

FTP 服務(wù)器必須在整個(gè)會(huì)話期間保留用戶的狀態(tài)

大大限制了 FTP 同時(shí)維持的會(huì)話總數(shù)。 而另一方面， HTTP 是無(wú)狀態(tài)的，即它不必對(duì)任何用 戶狀態(tài)進(jìn)行追蹤。

電子郵件

異步通信

用戶代理

郵件服務(wù)器

簡(jiǎn)單郵件傳輸協(xié)議SMTP

SMTP 要求每個(gè)報(bào)文(包括它們的體)使 用 7 比特 ASCII 碼格式

DNS

域名向IP地址的翻譯

主機(jī)別名

郵件服務(wù)器別名

負(fù)載均衡

分布式DNS

單點(diǎn)失敗問(wèn)題

流量問(wèn)題

距離問(wèn)題

維護(hù)性問(wèn)題

TCP的三次握手

第一次握手

• 客戶端向服務(wù)器發(fā)出連接請(qǐng)求報(bào)文，這時(shí)報(bào)文首部中的同部位SYN=1，同時(shí)隨機(jī)生成初始序列號(hào) seq=x，此時(shí)，TCP客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀
  態(tài)。TCP規(guī)定，SYN報(bào)文段（SYN=1的報(bào)文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個(gè)序號(hào)。這個(gè)三次握手中的開(kāi)始。表示客戶端想要和服務(wù)端建立連接

第二次握手

• TCP服務(wù)器收到請(qǐng)求報(bào)文后，如果同意連接，則發(fā)出確認(rèn)報(bào)文。確認(rèn)報(bào)文中應(yīng)該 ACK=1，SYN=1，確認(rèn)號(hào)是ack=x+1，同時(shí)也要為自己隨機(jī)初始化一個(gè)序列號(hào) seq=y，此
  時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。這個(gè)報(bào)文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個(gè)序號(hào)。這個(gè)報(bào)文帶有SYN(建立連接)和ACK(確認(rèn))標(biāo)志，詢問(wèn)客戶端
  是否準(zhǔn)備好

第三次握手

• TCP客戶進(jìn)程收到確認(rèn)后，還要向服務(wù)器給出確認(rèn)。確認(rèn)報(bào)文的ACK=1，ack=y+1，此時(shí)，TCP連接建立，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。
  TCP規(guī)定，ACK報(bào)文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號(hào)。這里客戶端表示我已經(jīng)準(zhǔn)備好

為什么TCP兩次握手不行

網(wǎng)絡(luò)不好的情況下，發(fā)送的請(qǐng)求沒(méi)有立刻到達(dá)服務(wù)端，而是在某個(gè)節(jié)點(diǎn)中滯留了，本來(lái)已失效，但如果server接收到的話，還是會(huì)向client節(jié)點(diǎn)發(fā)送報(bào)文，但請(qǐng)求已經(jīng)失效，client不會(huì)理會(huì)

客戶想要查詢一個(gè)IP地址

客戶端查詢根服務(wù)器

• 查詢com域名解析服務(wù)器

  • 查詢域名解析服務(wù)器

• 本地域名解析服務(wù)器無(wú)法解析域名的時(shí)候，訪問(wèn)根域名服務(wù)器

  • 權(quán)威域名服務(wù)器

不屬于層級(jí)體系

每個(gè)ISP都有

DNS查詢

迭代查詢

• 本地域名服務(wù)器向根域名服務(wù)器的查詢的迭代查詢
• 當(dāng)根域名服務(wù)器收到本地域名服務(wù)器發(fā)出的迭代查詢請(qǐng)求報(bào)文時(shí)，要么給出所要查詢的IP地址，要么告訴本地服務(wù)器：“你下一步應(yīng)當(dāng)向哪一個(gè)域名服務(wù)器進(jìn)行查詢

遞歸查詢

• 主機(jī)向本地域名服務(wù)器的查詢一般都是采用遞歸查詢
• 如果主機(jī)所詢問(wèn)的本地域名服務(wù)器不知道被查詢的域名的IP地址，那么本地域名服務(wù)器就以DNS客戶的身份，向其它根域名服務(wù)器繼續(xù)發(fā)出查詢請(qǐng)求報(bào)文(即替主機(jī)繼續(xù)查詢)，而不是讓主機(jī)自己進(jìn)行下一步查詢。

P2P

與傳統(tǒng)網(wǎng)絡(luò)技術(shù)的區(qū)別

• 每個(gè)節(jié)點(diǎn)既可以從其他節(jié)點(diǎn)得到服務(wù)，也可以向其他節(jié)點(diǎn)提供服務(wù)
• 服務(wù)器個(gè)數(shù)有多個(gè)
• 數(shù)據(jù)的一致性不易控制，系統(tǒng)不宜管理
• 可擴(kuò)展性好

結(jié)構(gòu)

• 分布式哈希表(DHT)結(jié)構(gòu)

  • 都是一個(gè)環(huán)行拓?fù)浣Y(jié)構(gòu)
  • 這個(gè)結(jié)構(gòu)里每個(gè)節(jié)點(diǎn)具有一個(gè)唯一的節(jié)點(diǎn)標(biāo)識(shí)
  • 這種結(jié)構(gòu)多用于文件共享和作為底層結(jié)構(gòu)用于流媒體傳輸

• 樹(shù)形結(jié)構(gòu)

  • 所有的節(jié)點(diǎn)都被組織在一棵樹(shù)中
  • 樹(shù)根只有子節(jié)點(diǎn)，樹(shù)葉只有父節(jié)點(diǎn)，其他節(jié)點(diǎn)既有子節(jié)點(diǎn)也有父節(jié)點(diǎn)
  • 信息的流向沿著樹(shù)枝流動(dòng)。最初的樹(shù)形結(jié)構(gòu)多用于P2P流媒體直播

• 網(wǎng)狀結(jié)構(gòu)

  • 所有的節(jié)點(diǎn)無(wú)規(guī)則地連在一起，沒(méi)有穩(wěn)定的關(guān)系，沒(méi)有父子關(guān)系
  • 網(wǎng)狀結(jié)構(gòu)為P2P提供了最大的容忍性、動(dòng)態(tài)適應(yīng)性
  • 流媒體直播、點(diǎn)播

作用

• 分布式科學(xué)計(jì)算

  • P2P技術(shù)可以使得眾多終端的CPU資源聯(lián)合起來(lái)，服務(wù)于一個(gè)共同的計(jì)算。這種計(jì)算一般是計(jì)算量巨大、數(shù)據(jù)極多、耗時(shí)很長(zhǎng)的科學(xué)計(jì)算
  • 每次的任務(wù)被分片
  • 不影響原有計(jì)算機(jī)使用的前提下，人們利用分散的CPU資源完成計(jì)算任務(wù)，并將結(jié)果返回給一個(gè)或多個(gè)服務(wù)器，將眾多結(jié)果進(jìn)行整合，以得到最終結(jié)果

• 文件共享

  • BitTorrent

    • BitTorrent中的節(jié)點(diǎn)在共享一個(gè)文件時(shí)，首先將文件分片并將文件和分片信息保存在一個(gè)流(Torrent)類型文件中，這種節(jié)點(diǎn)被形象地稱作“種子”節(jié)點(diǎn)
    • 其他用戶在下載該文件時(shí)根據(jù)Torrent文件的信息，將文件的部分分片下載下來(lái)，然后在其他下載該文件的節(jié)點(diǎn)之間共享自己已經(jīng)下載的分片，互通有無(wú)，從而實(shí)現(xiàn)文件的快速分發(fā)

  • 子主題 2

  • 子主題 3

• 流媒體直播與點(diǎn)播

HTTP 把每個(gè)對(duì)象封裝到它自己的 HTTP 響應(yīng)報(bào)文中， 而 SMTP 則把所有報(bào)文對(duì)象放在一個(gè)報(bào)文之中。

有限狀態(tài)機(jī)

輸入（事件）

輸出（響應(yīng)）

狀態(tài)（必須是可駐留的）

狀態(tài)變遷（由下一個(gè)事件觸發(fā)）

起始態(tài)

結(jié)束態(tài)（可選）

有限狀態(tài)機(jī)的重要性

• 計(jì)算機(jī)之所以能夠交互，對(duì)各種輸入有“反應(yīng)”，完全是因?yàn)獒槍?duì)每種輸入有預(yù)設(shè)的響應(yīng)

• 很多情況下，同一種輸入，我們期望在不同的狀態(tài)下有不同的結(jié)果——需要標(biāo)志狀態(tài)的機(jī)制

• 有限狀態(tài)機(jī)是描述各種輸入, 輸出與狀態(tài)之間關(guān)系, 便于協(xié)議實(shí)現(xiàn)的一種工具

• “智能化的”軟件、硬件邏輯都離不開(kāi)它

• 凡是沒(méi)有設(shè)計(jì)的輸入，計(jì)算機(jī)是不理睬的！——狀態(tài)機(jī)要保證完備性

rdt（可靠數(shù)據(jù)傳輸協(xié)議）

• 1.0

  • 完全可靠的底層信道

    • 沒(méi)有比特錯(cuò)誤
    • 沒(méi)有分組丟失

  • 發(fā)送方和接收方使用單獨(dú)的有限狀態(tài)機(jī)

    • 發(fā)送方發(fā)送數(shù)據(jù)到可靠信道
    • 接收方從可靠信道上讀數(shù)據(jù)

• 2.0

  • 存在比特錯(cuò)誤的信道

    • 底層信道可能出現(xiàn)比特錯(cuò)誤，但分組不丟失并按序到達(dá)

      • 用檢驗(yàn)和檢查比特錯(cuò)誤

      • 怎樣糾正錯(cuò)誤？類比打電話過(guò)程

        • 肯定確認(rèn)(ACKs): 接收方明確告訴發(fā)送方分組已被成功接收
        • 否定確認(rèn) (NAKs): 接收方明確告訴發(fā)送方分組有錯(cuò)誤
        • 發(fā)送方接收到NAK后將重傳分組

      • 自動(dòng)重傳請(qǐng)求（ARQ）協(xié)議

        • 基于重傳機(jī)制的可靠數(shù)據(jù)傳輸協(xié)議

    • 與rdt1.0比較

      • 接收方錯(cuò)誤檢測(cè)：檢錯(cuò)技術(shù) Vs 糾錯(cuò)技術(shù)
      • 接收方反饋: 控制報(bào)文 (ACK, NAK)
      • 自動(dòng)重傳：發(fā)送方->接收方

• 3.0

  • 具有丟失和錯(cuò)誤的信道

    • 底層信道也可能丟失分組，包括數(shù)據(jù)或 ACK分組

      • 問(wèn)題

        • 檢驗(yàn)和, 序號(hào), ACK和重傳仍然有用，但還不夠
        • 怎樣檢測(cè)丟包？丟包如何處理？需要增加新的協(xié)議機(jī)制

      • 方法

        • 發(fā)送方等待ACK一段“合理的”時(shí)間

        • 如果分組 (或 ACK) 僅僅是延遲了(而沒(méi)丟失)

          • 重傳將是冗余的, 但是使用序號(hào)的方法已經(jīng)可以解決這個(gè)問(wèn)題了
          • ACK中必須包含所確認(rèn)分組的序號(hào)

        • 如果在這段時(shí)間內(nèi)沒(méi)有收到ACK則重傳

        • 需要一個(gè)倒計(jì)時(shí)定時(shí)器

udp二元組

IP地址

目的端口號(hào)

TCP四元組

源IP地址

源端口

目的IP地址

目的端口

GBN協(xié)議

分組頭部包含k-bit序列號(hào)

• 窗口尺寸為N，最多允許N個(gè)分組未確認(rèn)

• ACK（n）

  • 確認(rèn)到序列號(hào)n的分組均已被正確吸收

  • ACK機(jī)制

    • 發(fā)送擁有最高序列號(hào)的、已被正確接受的分組的ACK

      • 可能產(chǎn)生重復(fù)的

      • 亂序到達(dá)的分組

        • 直接丟棄、接收方?jīng)]有緩存

• 超時(shí)事件

  • 重傳序列號(hào)大于N，還未收到ACK的所有分組

    • 累積確認(rèn)

缺點(diǎn)

• 接收方對(duì)每個(gè)分組單獨(dú)確認(rèn)

  • 設(shè)置緩存機(jī)制，緩存亂序到達(dá)的分組

• 發(fā)送方只重傳哪些沒(méi)收到ACK的分組

  • 限制已發(fā)送且未確認(rèn)的分組

計(jì)算機(jī)網(wǎng)絡(luò)運(yùn)輸層

運(yùn)輸層為相互通信的應(yīng)用進(jìn)程提供邏輯通信

IP協(xié)議：點(diǎn)到點(diǎn)（主機(jī)到主機(jī)）

• 運(yùn)輸層協(xié)議：端到端（進(jìn)程到進(jìn)程）

端口的作用：進(jìn)程間的通信

運(yùn)輸層很重要的功能：分用和復(fù)用

運(yùn)輸層對(duì)收到的報(bào)文進(jìn)行差錯(cuò)檢測(cè)

兩種不同的運(yùn)輸協(xié)議：面向連接的TCP和無(wú)連接的UDP

• UDP

  • UDP是無(wú)連接的、不保證可靠交付，面向報(bào)文、沒(méi)有擁塞控制
  • 面向協(xié)議
  • UDP使用盡最大努力交付，即不保證可靠交付
  • 支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信
  • 首部開(kāi)銷小，只有8個(gè)字節(jié)
  • 在計(jì)算校驗(yàn)和時(shí)，在UDP用戶數(shù)據(jù)報(bào)之前增加12個(gè)字節(jié)的偽首部。偽首部?jī)H僅是為了計(jì)算校驗(yàn)和

• TCP

  • TCP是面向連接的、提供可靠交付、連接只能是點(diǎn)對(duì)點(diǎn)（一對(duì)一）、面向字節(jié)流，以字節(jié)整數(shù)倍發(fā)送。

  • 應(yīng)用程序在使用TCP協(xié)議之前，必須先建立TCP連接。在傳送數(shù)據(jù)完畢后，必須釋放已經(jīng)建立的TCP連接

    • SR協(xié)議

      • 當(dāng)有分組出現(xiàn)超時(shí)

        • 重傳
        • 對(duì)每個(gè)分組分別確認(rèn)，不再只接收期望的，接到不期望的，就先緩存（設(shè)置緩存機(jī)制），接到期望的才交付上層
        • 發(fā)送方只需要重傳那些沒(méi)收到ACK的分組了
        • 產(chǎn)生了接收方窗口（GBN只有發(fā)送方窗口），用來(lái)緩存，現(xiàn)在有兩窗口了
        • 序列號(hào)的位數(shù)是K的話，那么得滿足 接收方窗口大小N+發(fā)送方N<= 2的k次方，防止因?yàn)榻邮辗紸CK丟失導(dǎo)致發(fā)送重發(fā)k號(hào)分組，而此時(shí)接收方滑到了新窗口，新窗口有新的k號(hào)分組（不是原來(lái)的，共用序號(hào)產(chǎn)生的），導(dǎo)致出錯(cuò)

  • TCP提供全雙工通信

  • TCP連接是一條虛連接（邏輯連接），而不是一條真正的物理連接

  • 長(zhǎng)度可變。化整為零，化零為整

  • TCP把連接作為最基本的抽象

  • TCP把連接的端點(diǎn)叫做套接字（socket）。端口號(hào)拼接到IP地址即構(gòu)成了套接字

  • TCP的流量控制

    • 意義

      • 讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來(lái)得及接收

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

      • 擁塞控制

        • 防止過(guò)多的數(shù)據(jù)注入網(wǎng)絡(luò)，從而避免網(wǎng)絡(luò)中的路由器或鏈路過(guò)載；是全局性的過(guò)程

          • 產(chǎn)生原因：對(duì)資源的需求總和大于可用資源

          • 它是一個(gè)動(dòng)態(tài)的問(wèn)題

          • 可以分為開(kāi)環(huán)控制和閉環(huán)控制

          • TCP進(jìn)行擁塞控制的算法有四種：慢開(kāi)始、擁塞避免、快重傳、快恢復(fù)

            • 慢開(kāi)始：由小到大逐漸增大擁塞窗口數(shù)值
            • 擁塞避免：每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口cwnd加1（加法增大）
            • 快重傳：發(fā)送方只要一連接收到3個(gè)重復(fù)確認(rèn)，立即進(jìn)行重傳
            • 快恢復(fù)：發(fā)送方知道只是丟失了個(gè)別報(bào)文段，不啟動(dòng)慢開(kāi)始。調(diào)整門(mén)限值ssthresh=cwnd/2，設(shè)置擁塞窗口cwnd=ssthresh，并開(kāi)始執(zhí)行擁塞避免算法

          • 擁塞窗口cwnd，大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口

      • 流量控制

        • 指點(diǎn)對(duì)點(diǎn)的通信量的控制；協(xié)調(diào)雙方速率；存在從收方到發(fā)放的直接反饋

    • 子主題 3

    • 子主題 4

套接字

• 套接字socket=(IP地址：端口號(hào))

  • 端口的作用

    • 對(duì)TCP/IP體系的應(yīng)用進(jìn)程進(jìn)行統(tǒng)一的標(biāo)志，使運(yùn)行不同操作系統(tǒng)的計(jì)算機(jī)的應(yīng)用進(jìn)程能夠互相通信

  • 復(fù)用

    • 應(yīng)用層所有的應(yīng)用進(jìn)程都可以通過(guò)運(yùn)輸層再傳送到IP層（網(wǎng)絡(luò)層）

  • 熟知端口號(hào)

    • 數(shù)值為0~1023

  • 登記端口號(hào)

    • 數(shù)值為1024~49151。標(biāo)志沒(méi)有熟知端口號(hào)的非常規(guī)的服務(wù)進(jìn)程

  • 客戶端使用的端口號(hào)（短暫端口號(hào)）

• 停止等待協(xié)議

  • 停止等待協(xié)議的優(yōu)點(diǎn)是簡(jiǎn)單，缺點(diǎn)是信道利用率太低

  • 流水線傳輸可提高信道利用率

  • 發(fā)送方每收到一個(gè)確認(rèn)，就把發(fā)送窗口向前滑動(dòng)一個(gè)分組的位置。接收方一般采用累積確認(rèn)的方式，接收方不必對(duì)收到的分組逐個(gè)發(fā)送確認(rèn)，而是在收到幾個(gè)分組后，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)

    • 以字節(jié)為單位的滑動(dòng)窗口

      • A的發(fā)送窗口一定不能超過(guò)B的接收窗口數(shù)值

      • 發(fā)送窗口的大小代表在還沒(méi)收到對(duì)方確認(rèn)消息的情況下，發(fā)送端最多可以發(fā)送多少數(shù)據(jù)

      • 接收窗口中是期望接收的數(shù)據(jù)的序號(hào)

      • B只能對(duì)按序收到的數(shù)據(jù)中的最高序號(hào)給出確認(rèn)

      • 發(fā)送緩存用來(lái)暫時(shí)存放

        • 發(fā)送應(yīng)用程序傳送給發(fā)送方TCP準(zhǔn)備發(fā)送的數(shù)據(jù)
        • TCP已發(fā)送出但尚未收到確認(rèn)的數(shù)據(jù)

      • 接收緩存用來(lái)暫時(shí)存放

        • 按序到達(dá)的、但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)
        • 未按序到達(dá)的數(shù)據(jù)

      • 在同一時(shí)刻，A的發(fā)送窗口并不總是和B的接收窗口一樣大

        • TCP通常對(duì)不按時(shí)到達(dá)的數(shù)據(jù)是先臨時(shí)存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應(yīng)用進(jìn)程
        • TCP要求接收方必須有累積確認(rèn)的功能，這樣可以減少傳輸開(kāi)銷

總結(jié)

以上是生活随笔為你收集整理的我与TCP连接不得不说的故事的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。