这就是物理层、数据链路层、网络层这三层所做的事情。站在第四层的你，就可以利用下三层所做的铺垫，随心所欲地发送数据，而不必担心找不到对方了。
虽然你此时还什么都没干，但你还是给自己这一层起了个响亮的名字，叫做传输层。你本以为自己所在的第四层万事大吉，啥事没有，但很快问题就接踵而至。问题来了
前三层协议只能把数据包从一个主机搬到另外一台主机，但是，到了目的地以后，数据包具体交给哪个程序（进程）呢？
但很快，你发现事情变得非常复杂...... 丢包问题
由于网络的不可靠，数据包可能在半路丢失，而 A 和 B 却无法察觉。
你管它叫停止等待协议。只要按照这个协议来，虽然 A 无法保证 B 一定能收到包，但 A 能够确认 B 是否收到了包，收不到就重试，尽最大努力让这个通信过程变得可靠，于是你们现在的通信过程又有了一个新的特征，可靠交付。效率问题
停止等待虽然能解决问题，但是效率太低了，A 原本可以在发完第一个数据包之后立刻开始发第二个数据包，但由于停止等待协议，A 必须等数据包到达了 B ，且 B 的 ACK 包又回到了 A，才可以继续发第二个数据包，这效率慢得可不是一点两点。于是你对这个过程进行了改进，采用流水线的方式，不再傻傻地等。
顺序问题
但是网路是复杂的、不可靠的。有的时候 A 发出去的数据包，分别走了不同的路由到达 B，可能无法保证和发送数据包时一样的顺序。
而 B 这个确认号意味深长：比如 B 发了一个确认号为 ack = 3，它不仅仅表示 A 发送的序号为 2 的包收到了，还表示 2 之前的数据包都收到了。这种方式叫累计确认或累计应答。
注意，实际上 ack 的号是收到的最后一个数据包的序号 seq + 1，也就是告诉对方下一个应该发的序号是多少。但图中为了便于理解，ack 就表示收到的那个序号，不必纠结。流量问题
有的时候，A 发送数据包的速度太快，而 B 的接收能力不够，但 B 却没有告知 A 这个情况。
B 告诉了 A 自己的窗口大小值，A 怎么利用它去做 A 这边发包的流量控制呢？很简单，假如 B 给 A 传过来的窗口大小 win = 5，那 A 根据这个值，把自己要发送的数据分成这么几类。
但是当 A 不断发包的同时，A 也会收到来自 B 的确认包，此时整个窗口会往右移动，因此上边界也往右移动，A 就能发更多的数据包了。
如果 A 收到了比原窗口值小的窗口大小，比如 win = 4，则 A 暂时不会改变窗口大小，更不会将窗口上边界向左移动，而是等着 ACK 的到来，不断将左边界向右移动，直到窗口大小值收缩到新大小为止。
OK，终于将流量控制问题解决得差不多了，你看着上面一个个小动图，给这个窗口起了一个更生动的名字，滑动窗口。拥塞问题
但有的时候，不是 B 的接受能力不够，而是网络不太好，造成了网络拥塞。
拥塞窗口大小的计算有很多复杂的算法，就不在本文中展开了，假如拥塞窗口的大小为 cwnd，上一部分流量控制的滑动窗口的大小为 rwnd，那么窗口的右边界受这两个值共同的影响，需要取它俩的最小值。窗口大小 = min(cwnd, rwnd)含义很容易理解，当 B 的接受能力比较差时，即使网络非常通畅，A 也需要根据 B 的接收能力限制自己的发送窗口。当网络环境比较差时，即使 B 有很强的接收能力，A 也要根据网络的拥塞情况来限制自己的发送窗口。正所谓受其短板的影响嘛~连接问题
有的时候，B 主机的相应进程还没有准备好或是挂掉了，A 就开始发送数据包，导致了浪费。
这个问题在于，A 在跟 B 通信之前，没有事先确认 B 是否已经准备好，就开始发了一连串的信息。就好比你和另一个人打电话，你还没有"喂"一下确认对方有没有在听，你就巴拉巴拉说了一堆。这个问题该怎么解决呢？地球人都知道，三次握手嘛！
A：我准备好了(SYN)
B：我知道了(ACK)，我也准备好了(SYN)
A：我知道了(ACK)
A 与 B 各自在内存中维护着自己的状态变量，三次握手之后，双方的状态都变成了连接已建立（ESTABLISHED）。虽然就只是发了三次数据包，并且在各自的内存中维护了状态变量，但这么说总觉得太 low，你看这个过程相当于双方建立连接的过程，于是你灵机一动，就叫它面向连接吧。注意：这个连接是虚拟的，是由 A 和 B 这两个终端共同维护的，在网络中的设备根本就不知道连接这回事儿！但凡事有始就有终，有了建立连接的过程，就要考虑释放连接的过程，又是地球人都知道，四次挥手嘛！
A：再见，我要关闭了(FIN)
B：我知道了(ACK)
给 B 一段时间把自己的事情处理完...
B：再见，我要关闭了(FIN)
A：我知道了(ACK)
总结
以上讲述的，就是 TCP 协议的核心思想，上面过程中需要传输的信息，就体现在 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，抱歉）
一提到 TCP，可能很多人都想起被三次握手和四次挥手所支配的恐惧。但其实你跟着文中的思路你就会发现，三次握手与四次挥手只占 TCP 所解决的核心问题中很小的一部分，只是因为它在面试中很适合作为知识点进行考察，所以在很多人的印象中就好像 TCP 的核心就是握手和挥手似的。后
