你是一台电脑，你的名字叫 A 图片 经过《你管这破玩意儿叫网络？》这篇文章中的一番折腾，只要你知道另一位伙伴 B 的 IP 地址，且你们之间的网络是通的，无论多远，你都可以将一个数据包发送给你的伙伴 B
这就是物理层、数据链路层、网络层这三层所做的事情。 站在第四层的你，就可以不要脸地利用下三层所做的铺垫，随心所欲地发送数据，而不必担心找不到对方了。 虽然你此时还什么都没干，但你还是给自己这一层起了个响亮的名字，叫做传输层。 你本以为自己所在的第四层万事大吉，啥事没有，但很快问题就接踵而至。 问题来了
前三层协议只能把数据包从一个主机搬到另外一台主机，但是，到了目的地以后，数据包具体交给哪个程序（进程）呢？ 图片 所以，你需要把通信的进程区分开来，于是就给每个进程分配一个数字编号，你给它起了一个响亮的名字：端口号。 图片 然后你在要发送的数据包上，增加了传输层的头部，源端口号与目标端口号。 图片 OK，这样你将原本主机到主机的通信，升级为了进程和进程之间的通信。 你没有意识到，你不知不觉实现了 UDP 协议！ （当然 UDP 协议中不光有源端口和目标端口，还有数据包长度和校验值，我们暂且略过） 就这样，你用 UDP 协议无忧无虑地同 B 进行着通信，一直没发生什么问题。
但很快，你发现事情变得非常复杂…
丢包问题
由于网络的不可靠，数据包可能在半路丢失，而 A 和 B 却无法察觉。
对于丢包问题，只要解决两个事就好了。 第一个，A 怎么知道包丢了？ 答案：让 B 告诉 A 第二个，丢了的包怎么办？ 答案：重传 于是你设计了如下方案，A 每发一个包，都必须收到来自 B 的确认（ACK），再发下一个，否则在一定时间内没有收到确认，就重传这个包。 图片 你管它叫停止等待协议。只要按照这个协议来，虽然 A 无法保证 B 一定能收到包，但 A 能够确认 B 是否收到了包，收不到就重试，尽最大努力让这个通信过程变得可靠，于是你们现在的通信过程又有了一个新的特征，可靠交付。
效率问题
停止等待虽然能解决问题，但是效率太低了，A 原本可以在发完第一个数据包之后立刻开始发第二个数据包，但由于停止等待协议，A 必须等数据包到达了 B ，且 B 的 ACK 包又回到了 A，才可以继续发第二个数据包，这效率慢得可不是一点两点。 于是你对这个过程进行了改进，采用流水线的方式，不再傻傻地等。
顺序问题
但是网路是复杂的、不可靠的。 有的时候 A 发出去的数据包，分别走了不同的路由到达 B，可能无法保证和发送数据包时一样的顺序。
在流水线中有多个数据包和ACK包在乱序流动，他们之间对应关系就乱掉了。 难道还回到停止等待协议？A 每收到一个包的确认（ACK）再发下一个包，那就根本不存在顺序问题。应该有更好的办法！ A 在发送的数据包中增加一个序号（seq），同时 B 要在 ACK 包上增加一个确认号（ack），这样不但解决了停止等待协议的效率问题，也通过这样标序号的方式解决了顺序问题。 图片 而 B 这个确认号意味深长：比如 B 发了一个确认号为 ack = 3，它不仅仅表示 A 发送的序号为 2 的包收到了，还表示 2 之前的数据包都收到了。这种方式叫累计确认或累计应答。 图片 注意，实际上 ack 的号是收到的最后一个数据包的序号 seq + 1，也就是告诉对方下一个应该发的序号是多少。但图中为了便于理解，ack 就表示收到的那个序号，不必纠结。
流量问题
有的时候，A 发送数据包的速度太快，而 B 的接收能力不够，但 B 却没有告知 A 这个情况。
怎么解决呢？ 很简单，B 告诉 A 自己的接收能力，A 根据 B 的接收能力，相应控制自己的发送速率，就好了。 B 怎么告诉 A 呢？B 跟 A 说"我很强"这三个字么？那肯定不行，得有一个严谨的规范。 于是 B 决定，每次发送数据包给 A 时，顺带传过来一个值，叫窗口大小（win)，这个值就表示 B 的接收能力。同理，每次 A 给 B 发包时也带上自己的窗口大小，表示 A 的接收能力。
B 告诉了 A 自己的窗口大小值，A 怎么利用它去做 A 这边发包的流量控制呢？ 很简单，假如 B 给 A 传过来的窗口大小 win = 5，那 A 根据这个值，把自己要发送的数据分成这么几类。 图片 图片过于清晰，就不再文字解释了。 当 A 不断发送数据包时，已发送的最后一个序号就往右移动，直到碰到了窗口的上边界，此时 A 就无法继续发包，达到了流量控制。 图片 但是当 A 不断发包的同时，A 也会收到来自 B 的确认包，此时整个窗口会往右移动，因此上边界也往右移动，A 就能发