【正文】 ，此傳輸?shù)刂肪捅粡U棄了。 ? 當(dāng)連接釋放的時(shí)候，各傳輸實(shí)體將此連接標(biāo)識(shí)信息添加到本機(jī)維護(hù)的一張過時(shí)連接表中。 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 分組的 TTL機(jī)制 ?原理 ? 利用 TTL丟棄超時(shí)分組。 ? 不能避免網(wǎng)絡(luò)層分組傳輸?shù)牟豢煽啃浴? ? A 發(fā)出序號(hào)為 X的第一個(gè)數(shù)據(jù) DATA，并確認(rèn) B的序號(hào)為 Y的接受連接確認(rèn)。 重復(fù)發(fā)送確認(rèn) ACK=z Data(seq=x, ACK=z) Back 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 釋放連接 ?非對(duì)稱式連接釋放方法 ? 一方發(fā)出釋放連接請(qǐng)求后，整個(gè)連接斷開。 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 兩軍問題 ?兩支藍(lán)軍如何能夠同時(shí)發(fā)送進(jìn)攻？ ? 藍(lán)兵穿越白軍防地是不可靠通信。 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 三次握手 + 定時(shí)器的方法釋放連接 ?在實(shí)際的通信過程中，使用三次握手 + 定時(shí)器的方法釋放連接，在絕大多數(shù)情況下是成功的。 Back 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 緩沖策略 ?由于網(wǎng)絡(luò)層服務(wù)是不可靠的，傳輸層實(shí)體必須緩存所有連接發(fā)出的 TPDU，而且為每個(gè)連接單獨(dú)做緩存，以便用于錯(cuò)誤情況下的重傳。 ?為了避免控制 TPDU丟失導(dǎo)致死鎖，主機(jī)應(yīng)該周期性的發(fā)送 TPDU。 ? UDP協(xié)議概述、 TPDU、工作原理。 ?TCP的傳輸實(shí)體一般為軟件實(shí)現(xiàn)： ? 一部分是用戶進(jìn)程。 ? 基于字節(jié)流： TCP連接是基于字節(jié)流的，而非報(bào)文，報(bào)文的邊界在端到端的傳輸中不能得到保留。 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 TCP的數(shù)據(jù)傳輸 ?發(fā)送和接收方的 TCP傳輸實(shí)體以數(shù)據(jù)段 (segment)的形式交換數(shù)據(jù)。 ? 決定段大小的兩個(gè)條件： ?適應(yīng) IP的負(fù)載能力，不能超過 65535字節(jié)的 IP分組限制。超時(shí)前沒有收到確認(rèn)，就重傳。對(duì)于緊急數(shù)據(jù)，可以使用 URGENT標(biāo)記。 ?序號(hào)和確認(rèn)號(hào)： ? 以字節(jié)編號(hào)，各 32bits。 ? URG：和緊急指針配合使用，發(fā)送緊急數(shù)據(jù)。 ? SYN：用于連接建立指示。 ? 為增加可靠性，對(duì) TCP頭，數(shù)據(jù)和偽 TCP報(bào)頭計(jì)算校驗(yàn)和。 ?可選項(xiàng)域（自學(xué)）。 ? 服務(wù)器方的傳輸實(shí)體接收到這個(gè) TCP段后，首先檢查是否有服務(wù)進(jìn)程在所請(qǐng)求的端口上監(jiān)聽。 ? 發(fā)起方收到確認(rèn)后，發(fā)出一個(gè) SYN置 1和 ACK置 1的 TCP段表示收到連接確認(rèn)段。 ? 根據(jù)接收緩沖區(qū)和來自應(yīng)用層數(shù)據(jù)確定策略。 ? 正常情況下，發(fā)送方不能再發(fā)送 TCP數(shù)據(jù)。 ? 接收 1BYTE時(shí)，會(huì)出現(xiàn) silly window syndrome問題，于是使用Clark算法來解決。 ? 當(dāng)編輯器處理完該字節(jié)，用 41字節(jié)的分組返回處理結(jié)果。 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 Clark算法解決接收 1BYTE的問題 ?使用 Clark算法解決 silly window syndrome。 ?TCP處理“快網(wǎng)絡(luò)小緩存”產(chǎn)生擁塞的措施 ? 在連接建立時(shí)聲明最大可接受段長(zhǎng)度。 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 圖例：擁塞的產(chǎn)生 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 慢啟動(dòng)算法 1. 連接建立時(shí)需要設(shè)置三個(gè)參數(shù)，可變發(fā)送窗口初始值、擁塞窗口初始值為該連接允許的最大段長(zhǎng)，閾值為 64K。 5. 當(dāng)超時(shí)發(fā)生時(shí)，閾值設(shè)置為當(dāng)前擁塞窗口大小的一半，擁塞窗口重新設(shè)置為一個(gè)最大段長(zhǎng)。在時(shí)鐘超時(shí)前，收到該段確認(rèn)，關(guān)閉此定時(shí)器。如果持續(xù)定時(shí)器超時(shí)，發(fā)送方向接收方發(fā)送一個(gè)探測(cè)數(shù)據(jù)，打破死鎖。時(shí)間長(zhǎng)度為分組 TTL的兩倍，以確保當(dāng)一個(gè)連接斷開之后，所有被此連接創(chuàng)建的分組都完全消失。發(fā)送一個(gè)段，啟動(dòng)重發(fā)定時(shí)器。 協(xié)議標(biāo)準(zhǔn)是 RFC768。 IP 報(bào)頭 UDP報(bào)頭 UDP 協(xié)議數(shù)據(jù)單元 TPDU 數(shù) 據(jù) 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 ?UDP報(bào)頭 格式 ?Source Port amp。 UDP的 TPDU ? 3 2 b i t s ?Sourc e IP Addre s sDes tina ti on IP Ad dre s s0 0 0 0 0 0 0 0 Protoc ol =1 7 UDP 長(zhǎng)度偽 U DP 報(bào)頭（信息取自 IP 報(bào)頭，計(jì)入校驗(yàn)和，用于檢錯(cuò)）計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 UDP協(xié)議的工作原理 ?用 216個(gè)端口區(qū)分不同的應(yīng)用進(jìn)程。 ? 匹配不成功，丟棄該 TPDU，回送“目的端口不可達(dá)”的ICMP數(shù)據(jù)報(bào)。 ? 發(fā)送端始終保持一個(gè)已發(fā)送但尚未確認(rèn)的幀的序號(hào)表，稱為發(fā)送窗口。 ? 接收端有一個(gè)接收窗口，大小固定，但不一定與發(fā)送窗口相同。接收窗口大小不變。 ? 接收窗口表示允許接收的信息幀，落在窗口外的幀均被丟棄。發(fā)送窗口 = 上界 — 下界，大小可變。其發(fā)送的 RIP路由請(qǐng)求報(bào)文如下。 ?接收主機(jī) ? 匹配 UDP報(bào)頭中目的端口的應(yīng)用進(jìn)程。 ?UDP length： UDP報(bào)文的長(zhǎng)度 ?UDP checksum： ? 可選，不計(jì)算校驗(yàn)和時(shí)取值為 0；計(jì)算校驗(yàn)和時(shí)取值為 1。 ? 即使出錯(cuò)重傳也必建立連接的開銷小。 ?如果在定時(shí)器超時(shí)之前確認(rèn)返回， TCP測(cè)量得到該確認(rèn)花費(fèi)的時(shí)間 M，并根據(jù)下面的公式修正 RTT： RTT=aRTT+(1a)M，其中 a是修正因子，一般 a=7/8。 ? 如果超時(shí)間隔＝ T1：超時(shí)間隔 過短，引起不必要的數(shù)據(jù)重傳 ? 如果超時(shí)間隔＝ T2：超時(shí)間隔 過長(zhǎng)，使得網(wǎng)絡(luò)性能下降 ?解決辦法 ? 根據(jù)對(duì)網(wǎng)絡(luò)性能的不斷測(cè)定， 采用一種不斷調(diào)整超時(shí)重發(fā)時(shí)間間隔的動(dòng)態(tài)算法。如果沒有得到相應(yīng)，就中止該連接。 ?問題：超時(shí)間隔設(shè)為多長(zhǎng)合理？？？ ? 持續(xù)定時(shí)器 (persistence timer) ?用于解決死鎖。直至超時(shí)或擁塞窗口等于接收方聲明的接收窗口大小，發(fā)生超時(shí)時(shí)轉(zhuǎn) 5)。 3. 發(fā)出 ( 擁塞窗口 /最大段長(zhǎng) )個(gè)最大長(zhǎng)度的 TCP段，若都得到確認(rèn)，則擁塞窗口加倍。 ?TCP處理“慢網(wǎng)絡(luò)大緩存”產(chǎn)生擁塞的措施 ? 發(fā)送方維護(hù)兩個(gè)窗口：可變發(fā)送窗口和擁塞窗口，按兩個(gè)窗口的最小值發(fā)送。 限制收方，只有在具備一半的空緩存或最大段長(zhǎng)的空緩存時(shí)，才產(chǎn)生一個(gè)窗口更新段。 IP報(bào)頭 TCP報(bào)頭 C IP報(bào)頭 TCP報(bào)頭 IP報(bào)頭 TCP報(bào)頭 IP報(bào)頭 TCP報(bào)頭 C 一個(gè) 字符 更新窗口 確認(rèn) 接收 返回處理結(jié)果 用戶端 ———— tel ———— 編輯器 計(jì) 算 機(jī) 網(wǎng) 絡(luò) 原 理 —— 傳 輸 層 Nagle算法解決發(fā)送 1BYTE的問題 ?Nagle算法： 當(dāng)應(yīng)用程序每次向傳輸實(shí)體發(fā)出一個(gè)字節(jié)時(shí)，傳輸實(shí)體發(fā)出第一個(gè)字節(jié)并緩存其后所有字節(jié)直至收到對(duì)第一個(gè)字節(jié)的確認(rèn)；然后發(fā)出所有已緩存的字節(jié)組段，緩存再收到的字節(jié)，直至收到下一個(gè)確認(rèn)。最糟糕的情況是： ? 當(dāng)一個(gè)字節(jié)到達(dá)負(fù)責(zé)發(fā)送的 TCP實(shí)體后， TCP創(chuàng)建一個(gè) 21字節(jié)的數(shù)據(jù)段，將其