TCP-IP協議 · php筆記

## TCP-IP協議 **author：xiak** **last update: 2021-11-25 11:22:33** ---- [TOC=3,8] > 我們上層應用寫的飛起，但總是出現奇怪的問題都是一臉懵，基礎知識非常缺乏，尤其是做php和前端的，可能連tcp是什么都說不清楚 > 因為應用開發基本接觸不到這些，都是給你封裝好了，天高皇帝遠，只知世間有 http 不知有 tcp > 我對 QUIC 大規模應用將會提高網絡效率的論調持懷疑態度，TCP/IP 已經歷了幾十年的驗證和修正，早已被驗證過是穩定可靠的，可能我是過于保守了，但是不要忘了 tcp 協議的精髓是它的自治策略，在網絡不穩定時它會犧牲個體的傳輸從而使整個網絡更加穩定，而 QUIC 不是這樣的，我不知道這種激進的策略在大規模網絡下會出現什么問題，一切有待驗證，并且新協議的推廣和普及也不是一兩天就可以做到的，即使被證明是有效的，也會在很長很長的時間內兩者共同存在。 ---- ### OSI七層網絡模型 / TCP/IP四層概念模型 ~~~ 5- Session 會話層 / 6- Presentation 表示層 7- Application 應用層 ↑↓ Binary byte: 應用數據: app首部 + 用戶數據（這只是為了界定業務數據的邊界，粘包問題） #4 Transport 傳輸層 (tcp傳輸協議，port號) ↑↓ Segment - TCP段: tcp首部 + 應用數據 #3 Network 網絡層 (ip地址) ↑↓ Datagram - IP數據報（Packet - IP數據包分組）: ip首部 + TCP段 Datagram: Packet{1, +} (fragment 分片) #2 Data Link 數據鏈路層 (網卡mac地址) ↑↓ Frame - 以太網幀: 以太網首部 + IP數據包 + 以太網尾部 length: 46 ~ 1500 #1 物理層 ↑↓ photon 光子 ~~~ ---- ### Wireshark 常用過濾規則（源：數據發送方，目標：數據接收方）數據鏈路層: 源mac地址目標mac地址網絡層: 源ip 目標ip 傳輸層: tcp/udp 源端口目標端口應用協議層: http 請求/響應頭字段/內容（響應是應用層的概念，對上層來說其實是一次數據發送） ---- ### 七層網絡模型 / 四層概念模型 <div class="table-box"><table border="1" cellspacing="0" cellpadding="0"><tbody><tr><td> OSI七層網絡模型 </td><td> <a href="https://so.csdn.net/so/search?from=pc_blog_highlight&q=Linux" target="_blank" class="hl hl-1">Linux</a> TCP/IP四層概念模型 </td><td> 對應網絡協議 </td></tr><tr><td> 應用層（Application） </td><td rowspan="3"> 應用層 </td><td> TFTP, FTP, NFS, WAIS </td></tr><tr><td> 表示層（Presentation） </td><td> Telnet, Rlogin, SNMP, Gopher </td></tr><tr><td> 會話層（Session） </td><td> SMTP, DNS </td></tr><tr><td> 傳輸層（Transport） </td><td> 傳輸層 </td><td> TCP, UDP </td></tr><tr><td> 網絡層（Network） </td><td> 網際層 </td><td> IP, ICMP, ARP, RARP, AKP, UUCP </td></tr><tr><td> 數據鏈路層（Data Link） </td><td rowspan="2"> 網絡接口 </td><td> FDDI, Ethernet, Arpanet, PDN, SLIP, PPP </td></tr><tr><td> 物理層（Physical） </td><td> IEEE 802.1A, IEEE 802.2到IEEE 802.11 </td></tr></tbody></table></div> ---- ### 擴展 [TCP 的那些事兒（上） | 酷殼 - CoolShell](https://coolshell.cn/articles/11564.html) [TCP 的那些事兒（下） | 酷殼 - CoolShell](https://coolshell.cn/articles/11609.html) > 但是TCP要解決一個很大的事，那就是要在一個網絡根據不同的情況來動態調整自己的發包的速度，**小則讓自己的連接更穩定，大則讓整個網絡更穩定。** > TCP的設計者覺得，一個偉大而牛逼的協議僅僅做到流控并不夠，因為流控只是網絡模型4層以上的事，TCP的還應該更聰明地知道整個網絡上的事。 [TCP/IP四層模型和OSI七層模型_whmnirvana的博客-CSDN博客](https://blog.csdn.net/whmnirvana/article/details/76985001) [【工具-WireShark】網絡HTTP抓包使用教程_Ric的博客-CSDN博客](https://lichong.blog.csdn.net/article/details/120820845) [通俗易懂TCP/IP（概述）](https://baijiahao.baidu.com/s?id=1679150230832085964&wfr=spider&for=pc) > 大物理學家費曼提出一個高效的費曼學習法，**即從問題入手，試著把問題都講出來**，以教代學，**一旦你能把問題都講清楚，便學會了。** [搞了半天，終于弄懂了TCP Socket數據的接收和發送，太難](http://www.360doc.com/content/20/0812/23/36242867_930032487.shtml) > 另一個反對排隊的論點是，它使應用程序在連接的另一端（客戶機）看起來很慢。客戶機將看到它可以建立新的TCP連接，但是當它嘗試使用它們時，服務器似乎響應非常慢。所以建議在這種情況下，最好是讓新的連接失敗，因為這樣可以提供更明顯的服務器不正常的反饋。 > 當用戶態的進程實際調用文件描述符上的read(2)時，它會導致內核從其接收緩沖區中刪除數據，并將該數據復制到此進程調用read(2)所提供的緩沖區中。 > > **接收讀取時直接刪除 read buffer 而不用等到 ack確認發送完畢（ack本身也不需要再ack了啊），發送時要等到對方 ack 確認到達才會刪除 write buffer** 。 > 讀語義：如果接收緩沖區已滿，而TCP連接的另一端嘗試發送更多的數據，內核將拒絕對數據包進行ACK。這只是常規的TCP擁塞控制。 > 寫語義：如果寫入隊列已滿，并且用戶調用寫入write(2)），則系統調用將被阻塞。 > 接收方 read buffer 滿（說明應用程序處理能力過載），**不再接受數據，不 ack 了，那么發送方 write buffer 很快也就滿了（等不到 ack 就不刪除 write buffer）**，不能再發了。這算是一種常規的TCP擁塞控制。 > > **發送能力會取決于對對方的接收能力，網絡能相互自適應調節**，網絡整體是自治的，最終整個網絡會向健康的方向發展，通信效率趨于最大化，這是 tcp協議的魅力所在。這就像是交通一樣，只要有秩序，就能減少擁堵，暢通無阻，都能平安到家。