本書結(jié)構(gòu)是自頂向下的铲敛，所以請按下列順序閱讀：

1.計算機網(wǎng)絡自頂向下--應用層
2.計算機網(wǎng)絡自頂向下--運輸層
3.計算機網(wǎng)絡自頂向下--網(wǎng)絡層
4.計算機網(wǎng)絡自頂向下--鏈路層

運輸層

概述和運輸層服務

• 運輸層協(xié)議為運行在不同主機的應用程序之間提供邏輯通信届宠，從應用角度看，運行不同進程的主機好像直接相連却嗡。其實他們可能分散在世界各地篡帕，通過路由器各種鏈路連接米间。
• 運輸層將應用程序接收到的報文轉(zhuǎn)換成運輸層分組（報文段）者春。將應用層報文劃分為小塊，為每塊加上運輸層首部以生成報文段

運輸層和網(wǎng)絡層的關(guān)系

• 網(wǎng)絡層提供了主機之間的邏輯通信辉懒，運輸層為不同主機的進程提供邏輯通信阳惹。以東西海岸兩個家庭互相寫信為例子，這個例子很經(jīng)典眶俩，大家可以多體會體會：
  • 進程 = 堂兄弟姐妹
  • 主機 = 家庭
  • 運輸層協(xié)議 = Ann 和 Bill（孩子里收信發(fā)信的大哥大姐）莹汤，分發(fā)到兄弟姐妹中，將信從一個人（進程）送到另一個人
  • 網(wǎng)絡層協(xié)議 = 郵政服務颠印，將信從一個家庭（主機）傳給另一個家庭
  • 運輸層協(xié)議只工作在主機（端）中 = Ann 和 Bill 只在家工作纲岭，將信拿到門口的郵箱
  • 多種運輸層協(xié)議，多種服務模型 = Ann 和 Bill 外出线罕，Susan 和 Harvey來收信發(fā)信止潮，結(jié)果年齡太小，收發(fā)郵件次數(shù)少钞楼，也老丟信
  • 運輸層服務受制于網(wǎng)絡層服務 = 郵政大哥若三天來一次喇闸，Ann和Bill就不可能兩天收發(fā)一次信
  • 運輸層協(xié)議能為應用程序提供可靠數(shù)據(jù)傳輸服務 = 若郵政大哥把信弄臟弄丟弄混，Ann 和 Bill 可以清理整理信件询件，或者讓對方下次重新發(fā)一次
  • 運輸層協(xié)議能確保應用程序報文不受入侵讀取 = 盡管郵政大哥可能被別人騙或者強行看了信件燃乍，Ann 和 Bill 也能規(guī)定加密方式對信的內(nèi)容進行加解密（還記得冒險小虎隊書嗎哈哈哈），弟弟妹妹們只需要看信的內(nèi)容
  • 多路分解 = Bill 和 Ann從郵遞大哥拿到信件宛琅，看收信人名字（端口號）刻蟹，然后分別交到他們手上
  • 多路復用 = Bill 和 Ann從弟弟妹妹手里拿到信件，幫他們裝填信封寫上信息

網(wǎng)絡運輸層概述

• RFC文檔等也將TCP的運輸層分組稱為報文段嘿辟，UDP分組稱為數(shù)據(jù)報舆瘪，本書將TCP和UDP分組統(tǒng)稱為報文段片效，網(wǎng)絡層分組稱為數(shù)據(jù)報（看情況）

多路復用與多路分解

• 將由網(wǎng)絡層提供的主機之間的交付服務—>延伸—>為應用程序提供正確的應用級進程之間的交付服務
• 計算機同時運行多個進程，運輸層需要將從網(wǎng)絡層接收到的數(shù)據(jù)定向到這些進程中的一個
  • 一個進程由一個或多個（單進程多線程）套接字socket英古，每個socket有唯一標識符淀衣，運輸層報文段中有端口號（用來指示socket），運輸層接收報文段檢查字段后將報文段定位到該socket哺呜，該工作稱為多路分解
  • 反之，從Socket中（應用層和運輸層接口）收集數(shù)據(jù)塊箕戳，并為每個數(shù)據(jù)塊裝填字段生成運輸層報文段某残，傳遞到網(wǎng)絡層的工作稱為多路復用
  • 運輸層報文段有源端口號和目的端口號。端口號為16bit的數(shù)陵吸，0_{65535玻墅，其中0}1023是周知端口號，受限制壮虫，留給HTTP澳厢、FTP之類的應用層協(xié)議使用。開發(fā)應用程序時囚似，必須為其分配一個端口號
• 無連接的多路復用和多路分解
  • 一個UDP socket由（目的IP地址剩拢，目的端口號）標識。注意是用來標識饶唤，不是只有這兩個相關(guān)字段徐伐，還有源端口號、源IP地址字段募狂。源端口號和目的端口號按傳遞方向反轉(zhuǎn)
• 面向連接的多路復用和多路分解
  • 一個TCP socket由（源IP地址办素，源端口號，目的IP地址祸穷，目的端口號）來標識
• 安全性：端口掃描
  • 如果發(fā)現(xiàn)一臺主機正在運行具有已知安全缺陷的應用程序性穿，比如在端口1434上監(jiān)聽的一臺SQL服務器遭受緩存溢出，使得一個遠程用戶能在易受攻擊的主機上執(zhí)行任意代碼
  • 比如前段時間（2017.5）的勒索比特幣的病毒雷滚，就是利用微軟給打印機開放的一個端口的漏洞需曾，導致很多政府部門、學校計算機癱瘓
• Web服務器與TCP
  • 考慮一臺運行在80端口上的Apache Web服務器祈远，當客戶們的瀏覽器向該服務器發(fā)送報文段時胯舷，所有報文段的目的端口都將是80。該服務器能夠根據(jù)源地址IP和源端口號區(qū)分來自不同客戶的報文段
  • socket與進程之間并非總是一一對應的關(guān)系绊含，可以為每個新的客戶連接創(chuàng)建具有新連接socket的新線程（這些線程都屬于同一個進程桑嘶，相當于socket和線程一一對應），也就是多個socket對應到一個進程

無連接運輸：UDP

• 概述
  • UDP只是做了運輸層能夠做的最少工作躬充，除了復用/分解功能及少量差錯檢測外逃顶，幾乎沒有對IP增加別的東西
  • UDP從應用進程拿到數(shù)據(jù)塊讨便，附加上用于多路復用分解的IP地址和端口號字段，和另外兩個小字段以政，將形成的報文段交給網(wǎng)絡層霸褒。網(wǎng)絡層再將其封裝到IP數(shù)據(jù)包，盡力交給對方主機盈蛮。
  • UDP發(fā)送報文段之前废菱，沒有跟接收方運輸層建立連接，所以它是無連接的抖誉。
  • DNS是使用UDP的應用層協(xié)議殊轴，當DNS應用程序想要進行一次查詢時，先構(gòu)造一個DNS報文交給UDP袒炉，UDP為此報文添加首部字段旁理，將形成的報文段給網(wǎng)絡層，網(wǎng)絡層將此UDP報文封裝進一個IP數(shù)據(jù)報中我磁，將其發(fā)送給一個DNS服務器孽文。查詢主機的DNS應用則等待響應。
  • 為何有些應用更適合UDP
    • 實時應用要求最小發(fā)送速率夺艰，不希望過分延遲報文段傳送芋哭，且能容忍一些數(shù)據(jù)丟失，TCP服務模型并不適合（當然了郁副，一個程序可以由很多部分楷掉，一些部分用TCP更適合）
    • 無需建立連接。因此DNS運行在UDP之上霞势，否則DNS會慢得多烹植。HTTP使用TCP是因為傳輸文本數(shù)據(jù)必須可靠，即使要承受其時延
    • 無連接狀態(tài)愕贡。TCP需要維護連接狀態(tài)草雕，各種緩存和參數(shù)。所以某些應用運行在UDP上可以支持更多活躍用戶
    • 分組首部開銷小固以，TCP報文段一般20字節(jié)墩虹，UDP8字節(jié)首部開銷
  • 應用
    • 流式多媒體、因特網(wǎng)電話（TCP越來越多）憨琳、網(wǎng)絡管理诫钓、路由選擇協(xié)議RIP、DNS
    • 如果不限制UDP篙螟，每個人都啟動高比特率視頻而不擁塞控制菌湃，路由器會有大量分組溢出，以至于幾乎沒有UDP分組能順利到達目的遍略，也會大大減小TCP的速率惧所，因此需要擁塞控制
    • UDP應用可以實現(xiàn)可靠數(shù)據(jù)傳輸（注意是應用實現(xiàn)的骤坐，UDP本身不能實現(xiàn)），比如增加確認與重傳機制下愈。
• UDP報文段結(jié)構(gòu)
  • 源端口號纽绍、目的端口號、長度势似、檢驗和（用來端到端差錯檢測）拌夏，每個8bit
  • 應用數(shù)據(jù)（報文）
• UDP檢驗和（差錯檢測，網(wǎng)絡層中會說）

可靠數(shù)據(jù)傳輸原理

• 構(gòu)造可靠數(shù)據(jù)傳輸協(xié)議
  • 經(jīng)完全可靠信道的可靠數(shù)據(jù)傳輸 rdt1.0
    • 有限狀態(tài)機
    • 有完全可靠的信道履因，接收方就不需要提供任何反饋信息給發(fā)送方
  • 經(jīng)具有比特差錯信道的可靠數(shù)據(jù)傳輸 rdt2.0
    • 自動重傳請求ARQ協(xié)議
      • 差錯檢測障簿。需要利用額外的比特（組原中海明碼、奇偶校驗碼之類）
      • 接收方反饋搓逾【硖福肯定確認ACK（收到了）杯拐，否定確認NAK（請再傳一遍）霞篡，接收方?jīng)]收到確認就不能發(fā)送（停等協(xié)議）
        • 考慮ACK、NAK分組受損的可能性端逼，在數(shù)據(jù)分組中添加新字段朗兵，分組序號0和1（向前取模）
      • 重傳。接收方收到有差錯分組
  • 經(jīng)具有比特差錯的丟包信道的可靠數(shù)據(jù)傳輸 rdt3.0
    • 發(fā)送方負責檢測和回復丟包工作顶滩，對每一個分組維護一個定時器余掖。如果在一個時間段內(nèi)沒收到ACK，則判定為丟包礁鲁，重傳分組盐欺，這也引入了冗余數(shù)據(jù)分組的可能性（時延很大的情況）
• 流水線可靠數(shù)據(jù)傳輸協(xié)議
  • rdt3.0的問題核心在于，它是一個停等協(xié)議仅醇，實際上大部分時間是在等待冗美，效率極低，解決方法：不適用停等方式運行析二，允許發(fā)送方發(fā)送多個分組無需等待確認粉洼，稱為流水線
  • 流水線對可靠數(shù)據(jù)傳輸協(xié)議的影響
    • 增加分組序號范圍，每個分組需要唯一序號
    • 協(xié)議發(fā)送方和接收方必須緩存多個分組叶摄，發(fā)送方最少能緩存已發(fā)送但未確認的分組属韧，接收方也可能需要緩存已正確接收的分組
    • 解決流水線差錯回復的兩種方法：回退N步GBN，選擇重傳SR
• 回退N步GBN（滑動窗口協(xié)議）
  • 分組序列被基序號（最早未確認分組序號）蛤吓、下一個序號（下一個要發(fā)的分組序號）宵喂，以及長度為N的窗口（包括未確認和未發(fā)送）分為四部分，分別是已確認会傲、未確認（已發(fā)送但未確認）樊破、未發(fā)送愉棱、不可用。其中窗口長度N為未確認分組數(shù)量的上限哲戚”蓟可以想象分組不斷被確認，窗口不斷右移的場景
  • GBN發(fā)送方需相應三種事件
    • 上層的調(diào)用顺少。發(fā)送方首先檢查窗口是否已滿朋其，若未滿則繼續(xù)發(fā)送，直到未確認分組充滿窗口脆炎；若窗口已滿梅猿，發(fā)送方將數(shù)據(jù)返回上層，說明窗口滿了秒裕，上層可能過會再試袱蚓。實際上發(fā)送方更可能緩存這些數(shù)據(jù)，或者使用同步機制（如信號量）使上層僅在窗口不滿的時候才調(diào)用
    • 收到一個ACK几蜻。累計確認喇潘，表明接收方已正確接收到序號為n及之前的所有分組，接收方窗口右移一個分組長度
    • 超時事件梭稚。若超時颖低，發(fā)送方重傳發(fā)送窗口里已發(fā)送但未確認的分組（這就是回退N步。假設窗口長度20弧烤，前10個未確認忱屑，后10個未發(fā)送，當?shù)弥?個分組發(fā)送超時的時候暇昂，回退到2重發(fā)2-10）
  • GBN接收方
    • 如果一個序號為n的分組被正確接收到并且按序莺戒，則接收方為分組n發(fā)送一個ACK，并將該分組交給上層急波。
    • 否則丟棄該分組（失序或損壞）从铲，并且為最近按序接收的分組重發(fā)ACK（發(fā)送方收到后會回退到失序的分組開始發(fā)送）。這樣接收方不需要緩存任何失序分組幔崖。唯一需要維護的就是下一個分組的序號食店，用來對比接收到的分組是否有序
    • 若分組k已接收并交付，則所有<k的分組也已經(jīng)交付赏寇，這就是累積確認
• 選擇重傳SR
  • GBN在窗口長度和帶寬時延積都很大時吉嫩，存在性能問題。單個分組差錯能引起GBN重傳大量分組
  • SR協(xié)議讓發(fā)送方僅重傳它懷疑在接收方出錯的分組嗅定，從而避免不必要重傳
  • SR發(fā)送方事件動作
    • 從上層收到數(shù)據(jù)自娩。如果序號位于發(fā)送方窗口內(nèi)（沒錯這個協(xié)議的邏輯也用窗口表示，不過要區(qū)分GBN），將數(shù)據(jù)打包并發(fā)送忙迁，否則緩存或返回上層
    • 超時脐彩。每個分組有自己的定時器（單個硬件定時器模擬多個邏輯定時器），超時后只發(fā)一個分組
    • 收到ACK姊扔。若該序號在窗口內(nèi)惠奸，將該分組標記為已接收（確認）。如果這個序號在窗口最左邊恰梢，那窗口就可以往右移到最小序號的未確認分組處（若是GBN只移動一個佛南，但SR未確認分組的下一個可能已確認，所以要跨過這些已確認嵌言。比如窗口20嗅回，1-10中1未確認，其他都已確認摧茴，當收到1的ACK時绵载，那窗口就能直接移動11的位置。GBN的話苛白，就必須回退到1重新傳1之后的所有分組）
  • SR接收方事件動作
    • 序號在rcv_base（接收方窗口的基序號娃豹，期待但未收到的最小序號，比它小的都收到了）開始的N長度窗口中被正確接收丸氛。收到的分組落在接收方窗口內(nèi)培愁，一個ACK發(fā)給發(fā)送方（可能有失序的分組著摔，窗口后面有的收到了缓窜，前面有的沒收到）。若序號等于基序號谍咆，則該分組以及以前緩存的序號連續(xù)的分組交付給上層禾锤，窗口右移（比如窗口有20個，第1個未收到摹察，但是后面9個收到了恩掷，若第1個也收到，就直接交付1-10供嚎，窗口右移10個）
    • 序號在基序號前的分組正確接收黄娘。接收方重新確認并回發(fā)ACK。因為發(fā)送方和接收方的窗口并不是總一致的（比如一個ACK丟了克滴，發(fā)送方重傳該分組逼争，要是接收方不確認，那就會一直發(fā)這個分組劝赔，導致窗口無法移動）
  • 其他情況誓焦，忽略分組
• 若分組序號有限，可能會產(chǎn)生不同步導致嚴重后果着帽，無法區(qū)分這一序號是新的分組還是舊的已經(jīng)確認的分組杂伟。對SR協(xié)議而言移层，窗口長度N必須小于等于序號空間大小的一半
• 現(xiàn)實中，分組在發(fā)送方和接收方可能會被重新排序赫粥。由于序號可以被重新使用观话，因此發(fā)送方需要確信任何先前發(fā)送的序號都不在網(wǎng)絡中。通過假定一個分組在網(wǎng)絡中存活時間不會超過某個固定最大時間來做到這一點越平。在TCP擴展中匪燕，最長分組壽命為3分鐘。改變使用序號的方法可以完全避免重新排序問題

面向連接的運輸：TCP

• TCP連接
  • TCP連接雙方都將初始化與之相關(guān)的TCP狀態(tài)變量喧笔，連接狀態(tài)完全保留在兩個端系統(tǒng)（主機）中帽驯。
  • TCP協(xié)議只在端系統(tǒng)中運行，中間網(wǎng)絡元素不會維持TCP連接狀態(tài)书闸，路由器對TCP連接視而不見尼变，他們看到的只是數(shù)據(jù)報
  • 全雙工服務，點對點服務
  • 三次握手建立連接
    • 客戶先發(fā)送一個特殊的TCP報文段
    • 服務器用另一個特殊的TCP報文段響應
    • 客戶用第三個報文段作為響應浆劲，同時可以承載應用層數(shù)據(jù)
  • 客戶進程通過socket（進程之門）傳遞數(shù)據(jù)流嫌术，數(shù)據(jù)一旦通過該門，就由客戶運行的TCP控制
  • TCP連接的組成：主機上的收發(fā)緩存牌借、變量度气、socket
• TCP報文段結(jié)構(gòu)
  • 源端口號、目的端口號
  • 檢驗和
  • 32bit的序號字段膨报、32bit的確認號字段
    • 實現(xiàn)可靠數(shù)據(jù)傳輸服務
    • 一個報文段的序號是該報文段首字節(jié)的字節(jié)流編號
    • 主機A填充進報文段的確認號是主機A期望從主機B收到的下一字節(jié)的序號
    • 累積確認磷籍，TCP只確認該流中至第一個丟失字節(jié)為止的字節(jié)。如A收到B的0_535和9001000现柠，還沒收到536~899院领，則A到B的下一個報文段將在確認號中包括536
  • 16bit接收窗口字段
    • 用于流量控制，指示接收方愿意接收的字節(jié)數(shù)量
  • 選項字段
    • 發(fā)送接收方協(xié)商最大報文段長度
    • 高速網(wǎng)絡環(huán)境下用作窗口調(diào)節(jié)因子
  • 4bit首部長度字段够吩，指示TCP首部長度
    • 因為選項字段的存在比然，TCP首部長度是可變的
  • 6bit的標志字段
    • 如ACK比特等
• 往返時間的估計與超時
  • TCP采用超時/重傳機制處理報文段丟失
  • 估計往返時間
    • TCP維護一個SampleRTT均值，代入公式更新估計時間
  • 設置和管理重傳超時間隔
    • 超時間隔 = 估計RTT + 4*偏差RTT
  • TCP發(fā)送方使用了流水線
• 可靠數(shù)據(jù)傳輸
  • 三種情況
    • A向B發(fā)送一個報文段周循，序號92强法，包含8字節(jié)，交給IP后開始等待一個來自B的確認號為100的報文段湾笛。然而確認報文段丟失饮怯，超時，A又重發(fā)相同報文段迄本。B收到后對比序號發(fā)現(xiàn)已經(jīng)收到過該報文段的一些字節(jié)硕淑，于是B的TCP確認后，將報文段重復的字節(jié)丟棄
    • A連續(xù)發(fā)了兩個報文段，92置媳，8和100于樟，20（序號和字節(jié)）。B收到兩個報文段并發(fā)送確認100和200拇囊。超時前沒有一個確認到達A迂曲，超時后A重傳92，8的報文，重啟定時器。只要第二個報文的ACK在新的超時以前發(fā)生到達甩苛，第二個報文就不會重傳纳本。
    • 和上面一種一樣分井，A發(fā)送兩個報文段，第一個報文段的確認在網(wǎng)絡丟失，但是超時之前收到了第二個報文段的確認報文。因為累積確認機制章姓，A知道B已經(jīng)收到第二個以及之前的報文，不會重傳了
  • 超時間隔加倍
    • 實際大多數(shù)情況下识埋，每次TCP重傳時會將下次超時間隔設為先前的兩倍
    • 當定時器在另外兩個事件（收到上層應用數(shù)據(jù)凡伊，收到ACK）中的任意一個啟動時，超時間隔又從估計RTT和偏差RTT推算得到窒舟。比如一個報文段第一次超時1s系忙，重發(fā)，第二次超時就是2s惠豺，第三次4s...但是當收到該報文確認時银还，超時間隔又重置，算是一種擁塞控制
  • 快速重傳
    • 發(fā)送方挨個發(fā)送大量報文段耕腾，如果一個丟失见剩，很可能引起一個接一個冗余ACK（即重復的ACK杀糯，上面說過扫俺，A連續(xù)發(fā)了序號為1，2固翰，3狼纬，4，5的報文骂际，若B沒收到2疗琉，卻收到了3，4歉铝，5盈简，則對2之后的報文都發(fā)送確認號為2的ACK）。如果TCP發(fā)送方接收到對相同數(shù)據(jù)的3個冗余ACK，它把這當做一種指示柠贤，說明這個重復確認報文段后面的報文都丟失了香浩。一旦收到3個冗余ACK，TCP執(zhí)行快速重傳臼勉，即在該報文段的定時器過期之前重傳丟失的報文段
  • 回退N步 or 選擇重傳
    • TCP確認是累積式的邻吭，正確接收但失序的報文段是不會被接收方逐個確認的，像GBN風格
    • 但是TCP和GBN有顯著區(qū)別
      • 許多TCP實現(xiàn)會將正確接收但失序的報文段緩存起來
      • GBN不僅重傳未確認分組宴霸，還會重傳之后所有分組囱晴，TCP只傳一個或不傳（若其后面的ACK超時前到來）
    • 選擇確認，允許接收方有選擇地確認失序報文段瓢谢，而不是累積確認最后一個正確接收的有序報文段畸写。該機制與選擇重傳機制結(jié)合（跳過重傳已確認報文段），TCP看起來像SR
    • TCP的差錯恢復機制是GBN協(xié)議和SR協(xié)議的混合體
• 流量控制
  • 一條TCP連接每一側(cè)主機都設置了緩存氓扛，當TCP連接收到正確有序的字節(jié)后艺糜，將數(shù)據(jù)放入緩存，應用從緩存中讀取幢尚。若應用較忙破停，發(fā)送方發(fā)送太快太多，可能會造成緩存溢出
  • 流量控制是一個速度匹配服務尉剩，發(fā)送方發(fā)送速率與接收方程序讀取速率相匹配
  • TCP發(fā)送方因為IP網(wǎng)絡的擁塞而降速（超時間隔加倍）真慢，屬于擁塞控制，不屬于流量控制理茎，雖然都是降速
  • TCP讓發(fā)送方維護一個稱為接收窗口rwnd的變量黑界，用于給發(fā)送方指示接收方還有多少可用緩存。因為是全雙工通信皂林，雙方都維護接收窗口變量
  • B把rwnd值放入給A的報文段接收窗口字段中朗鸠，通知A自己還有多少緩存空間，A控制未確認的數(shù)據(jù)量小于rwnd
  • 當B的rwnd為0時础倍，A繼續(xù)發(fā)送只有一個字節(jié)數(shù)據(jù)的報文段烛占，B確認，緩存開始清空沟启，確認報文里包含一個非0的rwnd值（B的rwnd為0時忆家，A收到后就不發(fā)的話，那B就一直空了德迹，A就一直不發(fā)了）
  • UDP無流量控制芽卿，緩存溢出就溢出了
• TCP連接管理（必考喲）
  • TCP建立連接（三次握手），假設客戶主機一進程想與服務器一進程建立一條連接：
    1. 客戶TCP向服務器TCP發(fā)送一個特殊TCP報文段（不含應用層數(shù)據(jù)）胳搞，報文段首部標志位SYN置為1（因此該特殊報文段也叫SYN報文段）卸例〕蒲睿客戶隨機選擇一個初始序號client_isn放在序號字段中。該報文段封裝在IP數(shù)據(jù)報中筷转，發(fā)送給服務器
    2. 服務器收到SYN報文段列另，為該TCP分配TCP緩存和變量，然后向客戶TCP發(fā)送允許連接的報文段（不含應用層數(shù)據(jù)）旦装。報文段首部中页衙，SYN置為1，確認號字段置為初始序號client_isn+1阴绢，服務器選擇自己的初始序號server_isn店乐。該報文段也叫SYNACK報文段
    3. 客戶收到SYNACK報文段后，客戶給該TCP連接分配緩存和變量呻袭。然后客戶給服務器發(fā)送第三個報文段眨八，對SYNACK報文段進行了確認，確認號置為server_isn+1左电，SYN字段置為0廉侧，序號為client_isn+1。這第三個報文段可以負載客戶的應用層數(shù)據(jù)篓足。建立TCP連接后段誊，之后每個報文段SYN都為0
    • 為何要三次？類比攀巖者和保護者（位于攀巖者下方栈拖，處理攀巖者的安全繩索）
  • TCP結(jié)束連接（四次揮手）连舍，假設客戶想關(guān)閉連接
    1. 客戶TCP向服務器發(fā)送一個終止報文段，首部標志位FIN置1
    2. 服務器收到后涩哟，向客戶會送一個確認報文段
    3. 服務器再發(fā)送它自己的終止報文段索赏，F(xiàn)IN置為1
    4. 客戶收到后，向服務器發(fā)送確認報文段
    • 關(guān)閉連接后贴彼，客戶端所有資源釋放（包括變量潜腻、緩存、端口號等等）
  • 安全性：SYN泛洪攻擊
    • 攻擊者發(fā)送大量TCP SYN報文段器仗，而不完成第三次握手融涣，服務器不斷為這些半開連接分配資源，導致服務器連接資源消耗殆盡
    • SYN cookie防御系統(tǒng)青灼，服務器收到SYN報文段先生成一個cookie（根據(jù)IP地址暴心、端口號字段，和該服務器唯一知道的一個散列函數(shù)）杂拨，而不分配資源。若客戶返回ACK悯衬，則跟cookie對比弹沽，對上才分配資源
  • 連接不匹配
    • 若主機收到一個TCP報文段檀夹，目的端口是80，但是主機80不接受連接策橘，則會返回一個報文段炸渡，RST標志位置1，告訴主機沒有該報文段的socket丽已，不要再發(fā)
    • 若主機收到一個UDP分組蚌堵，目的端口與當前UDPsocket不匹配，則發(fā)送一個特殊ICMP數(shù)據(jù)報（網(wǎng)絡層里講）

擁塞控制原理

• 丟包一般是當前網(wǎng)絡擁塞時由于路由器緩存溢出引起沛婴，因此分組重傳能作為網(wǎng)絡擁塞的征兆吼畏，但分組重傳無法解決網(wǎng)絡擁塞

• 擁塞原因與代價

  1. 情況一：兩個發(fā)送方和一臺無窮大緩存的路由器
     • 容量為R的共享式輸出鏈路上傳輸
     • 當發(fā)送速率超過R/2時，路由器的排隊分組就會無限增加嘁灯，源和目的平均時延變成無窮大
  2. 情況二：兩個發(fā)送方和一臺有限緩存的路由器
     • 分組到達一個已滿的緩存時會被丟棄泻蚊，發(fā)送方必須執(zhí)行重傳以補償因為緩存溢出丟棄的分組
     • 發(fā)送方遇到高時延時，進行的不必要重傳引起路由器轉(zhuǎn)發(fā)不必要的分組副本
  3. 情況三：4個發(fā)送方和具有優(yōu)先緩存的多臺路由器及多條路徑
     • 當一個分組沿一條路徑被丟棄時丑婿，每個上游路由器用于轉(zhuǎn)發(fā)該分組到丟棄該分組使用的傳輸容量被浪費

• 擁塞控制方法

  • 端到端擁塞控制
    • 網(wǎng)絡層沒有為運輸層擁塞控制提供反饋信息性雄，端系統(tǒng)通過對網(wǎng)絡行為的觀察（分組丟失與時延）來推斷
    • TCP報文段的丟失（超時/3次冗余確認）認為網(wǎng)絡擁塞，TCP相應減小窗口長度
    • RTT增加—>擁塞程度增加
  • 網(wǎng)絡輔助的擁塞控制
    • 路由器向發(fā)送方提供關(guān)于網(wǎng)絡擁塞狀態(tài)的顯式反饋信息羹奉，有兩種方式
      1. 路由器發(fā)給發(fā)送方一個通知秒旋，采用阻塞分組形式（也就是告訴說：『我擁塞了』）
      2. 路由器標記從發(fā)送方流向接收方分組的某個字段，來指示擁塞產(chǎn)生诀拭。接收方看到后滩褥，再向發(fā)送方通知網(wǎng)絡擁塞

• 網(wǎng)絡輔助擁塞控制例子

  • ATM（異步傳遞方式）
    • 面向虛電路VC的方法來處理分組交換，從源到目的地路徑上每臺交換機都維護有關(guān)源到目的地VC的狀態(tài)
    • 這種逐個VC的狀態(tài)允許交換機跟蹤各個發(fā)送方的行為（如平均傳輸速率）炫加，采取擁塞控制動作（如當交換機擁塞時瑰煎，向發(fā)送方發(fā)送顯式信令，減少它的速率
  • ABR（可用比特率服務）
    • 一種彈性數(shù)據(jù)傳輸服務
    • 當網(wǎng)絡輕載時俗孝，AR服務充分利用空閑可用帶寬酒甸；擁塞時，將傳輸速率抑制為預定好的最小傳輸速率
  • ATM ABR服務的擁塞控制框架
    • 基于速率赋铝，發(fā)送方明確計算出它能所發(fā)送的最大速率插勤，并據(jù)此進行相應調(diào)整

• TCP擁塞控制

  • TCP必須用端到端擁塞控制，因為IP層不向端系統(tǒng)提供顯式網(wǎng)絡擁塞反饋
  • TCP讓每一個發(fā)送方根據(jù)感知到的擁塞程度限制其發(fā)送速率
    • 如何限制其發(fā)送速率革骨？
      • 維護擁塞窗口cwnd值（注意流量控制使用接收窗口rwnd值）
      • 發(fā)送方未確認數(shù)據(jù)量 <= min { cwnd , rwnd }
    • 如何感知它到目的地路徑存在擁塞农尖？
      • 丟包：超時或收到3個冗余ACK
  • TCP是自計時的，使用確認來觸發(fā)增大它的擁塞窗口長度（及其傳輸速率）
  • TCP發(fā)送方如何確定發(fā)送速率良哲？
    • 一個丟失的報文意味著擁塞盛卡，當丟失報文段時應當降低速率（當前速度不能正常交付，得慢點）
    • 先前未確認報文段的確認到達時筑凫，增加發(fā)送方速率（當前速度能夠正常交付滑沧，說明可以再快點）
    • 帶寬探測（試探）：TCP發(fā)送方增加速率并村，丟包，從該速率后退滓技，再往前探測....（因為擁塞情況是波動的哩牍，得盡力保持在最高速率）

• TCP擁塞控制算法（TCP Reno）

  1. 慢啟動
     • 一開始cwnd只設為一個MSS的較小值（這就是『慢』，不過瞬間指數(shù)級加速）
     • 收到一個確認令漂，cwnd增加一個MSS ——> 每過一個RTT膝昆，cwnd翻番，發(fā)送速率翻倍（1叠必，2荚孵，4...每次發(fā)的也多一個）
     • 丟包（擁塞）結(jié)束慢啟動
       • 將ssthresh（慢啟動閾值）設置為cwnd/2，cwnd置為1重新開始慢啟動
       • 當cwnd=ssthresh時挠唆，結(jié)束慢啟動处窥，TCP轉(zhuǎn)移到擁塞避免模式
       • 收到3個冗余ACK，執(zhí)行快速重傳玄组，進入快速回復模式
  2. 擁塞避免
     • 進入擁塞避免狀態(tài)滔驾，cwnd值是上次遇到擁塞時的一半
     • 每個RTT只將cwnd值增加一個MSS/cwnd字節(jié)
     • 丟包，結(jié)束擁塞避免
       • 超時：ssthresh更新為cwnd的一半俄讹，cwnd置為1個MSS哆致，返回慢啟動狀態(tài)
       • 3冗余ACK：ssthresh更新為cwnd的一半，cwnd值減半患膛，進入快速恢復狀態(tài)
  3. 快速恢復
     • 快速恢復中摊阀，每個冗余ACK，cwnd 增加一個MSS踪蹬，當丟失報文的ACK到達時胞此，TCP降低cwnd，進入擁塞避免狀態(tài)
     • 超時：同慢啟動和擁塞避免

• TCP擁塞控制回顧

  • TCP擁塞控制常被稱為加性增（+1*MSS）跃捣，乘性減（cwnd/2）擁塞控制漱牵，產(chǎn)生鋸齒狀行為（發(fā)送速率折線圖）
  • TCP Vegas算法

• 對TCP吞吐量的宏觀描述

  • 在一個RTT內(nèi)，TCP發(fā)送數(shù)據(jù)的速率是cwnd與當前RTT的函數(shù)
  • 一條連接的平均吞吐量 = (0.75*W)/RTT 疚漆，其中W是窗口長度字節(jié)

• TCP擁塞控制公平性

  • 公平性和UDP
    • 許多多媒體應用不想傳輸速率被遏制酣胀，即使網(wǎng)絡非常擁塞，所以在UDP上運行娶聘。這些應用以更定速率將其數(shù)據(jù)注入網(wǎng)絡闻镶，寧愿丟包，也不愿將發(fā)送速率將至『公平』級別且不丟包
    • TCP角度來看丸升，UDP是不公平的铆农，UDP源可能會壓制TCP流量
  • 公平性和并行TCP連接
    • 除了UDP，我們也沒辦法阻止TCP應用使用多個并行連接发钝。當一個應用使用并行連接顿涣，會占用一條擁塞鏈路中較大比例的帶寬

• 當前新的運輸層協(xié)議

  • 數(shù)據(jù)包擁塞控制協(xié)議：相當于有擁塞控制的UDP波闹，與TCP兼容
  • 流控制傳輸協(xié)議
  • TCP友好速率控制協(xié)議（是一種擁塞控制協(xié)議）：為了平滑鋸齒狀行為酝豪，維護一種長期發(fā)送速率