本文来自微信公众号：低并发编程 （ID：dibingfa），作者：闪客
你是一台电脑，你的名字叫 A
经过《如果让你来设计网络》这篇文章中的一番折腾，只要你知道另一位伙伴 B 的 IP 地址，且你们之间的网络是通的，无论多远，你都可以将一个数据包发送给你的伙伴 B
这就是物理层、数据链路层、网络层这三层所做的事情。
站在第四层的你，就可以不要脸地利用下三层所做的铺垫，随心所欲地发送数据，而不必担心找不到对方了。
所以，你需要把通信的进程区分开来，于是就给每个进程分配一个数字编号，你给它起了一个响亮的名字：端口号。
然后你在要发送的数据包上，增加了传输层的头部，源端口号与目标端口号。
OK，这样你将原本主机到主机的通信，升级为了进程和进程之间的通信。
你没有意识到，你不知不觉实现了 UDP 协议！
（当然 UDP 协议中不光有源端口和目标端口，还有数据包长度和校验值，我们暂且略过）
就这样，你用 UDP 协议无忧无虑地同 B 进行着通信，一直没发生什么问题。
图片过于清晰，就不再文字解释了。
当 A 不断发送数据包时，已发送的最后一个序号就往右移动，直到碰到了窗口的上边界，此时 A 就无法继续发包，达到了流量控制。
不知道你现在再看下面这句话，是否能理解：
TCP 是
面向连接的、可靠的、基于字节流的
传输层通信协议
面向连接、可靠，这两个词通过上面的讲述很容易理解，那什么叫做基于字节流呢？
很简单，TCP 在建立连接时，需要告诉对方 MSS（最大报文段大小）。
也就是说，如果要发送的数据很大，在 TCP 层是需要按照 MSS 来切割成一个个的 TCP 报文段 的。
切割的时候我才不管你原来的数据表示什么意思，需要在哪里断句啥的，我就把它当成一串毫无意义的字节，在我想要切割的地方咔嚓就来一刀，标上序号，只要接收方再根据这个序号拼成最终想要的完整数据就行了。
在我 TCP 传输这里，我就把它当做一个个的字节，也就是基于字节流的含义了。
最后留给大家一个作业，模拟 A 与 B 建立一个 TCP 连接。
第一题：A 给 B 发送 “aaa” ，然后 B 给 A 回复一个简单的字符串 “success”，并将此过程抓包。
第二题：A 给 B 发送 “aaaaaa … a” 超过最大报文段大小，然后 B 给 A 回复一个简单的字符串 “success”，并将此过程抓包。
下面是我抓的包（第二题）
三次握手阶段
A -> B [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 B - >A [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1424 WS=512 A -> B [ACK] Seq=1 Ack=1 Win=132352 Len=0
数据发送阶段
A -> B [ACK] Seq=1 Ack=1 Win=132352 Len=1424 A -> B [ACK] Seq=1425 Ack=1 Win=132352 Len=1424 A -> B [PSH, ACK] Seq=2849 Ack=1 Win=132352 Len=1247 B -> A [ACK] Seq=1 Ack=1425 Win=32256 Len=0 B -> A [ACK] Seq=1 Ack=2849 Win=35328 Len=0 B -> A [ACK] Seq=1 Ack=4096 Win=37888 Len=0 B -> A [PSH, ACK] Seq=1 Ack=4096 Win=37888 Len=7
四次挥手阶段
B -> A[FIN, ACK] Seq=8 Ack=4096 Win=37888 Len=0 A -> B[ACK] Seq=4096 Ack=9 Win=132352 Len=0 A -> B [FIN, ACK] Seq=4096 Ack=9 Win=132352 Len=0（下面少复制了一行 ACK，抱歉）
本文来自微信公众号：低并发编程 （ID：dibingfa），作者：闪客
支付宝扫一扫
微信扫一扫
