3.5.1 TCP连接
TCP进行传输之间要进行三次握手建立连接，这个连接不是物理意义上的有一根电线连接，而是应用端两个应用，在逻辑上是已经建立连接了。
TCP 不需要传输的时候会进行四次挥手断开连接。
持续连接：在传输过程中一直保持连接，直到没有数据可以传输。
非持续连接：指传输完一组数据就断开连接，在传输就要建立新的连接。
3.5.2 TCP报文段结构
|
源端口号 |
目的端口号 |
|||||||
|
序号 |
||||||||
|
确认号 |
||||||||
|
首部长度 |
保留未用 |
URG |
ACK |
PSH |
RST |
SYN |
FIN |
接收窗口 |
|
因特网检验和 |
紧急数据指针 |
|||||||
|
选项 |
||||||||
|
数据 |
||||||||
源端口号，目的端口号：略
序号：就是第一个字节的序号，例如总共1000位，成2个报文段，第一个报文段序号是0， 第二个报文段序号是500
确认号：表示N之前的字段全部接收到了
首部长度：4比特，通常首部长度20个字节。20 * 8bit，本来应该是24个字节，但是选 项字段一般为空，所以就是20个字节。
URG：标记是否紧急
ACK：确认bit
PSH：被标记，表示接收方应该立即提交给上层数据
RST，SYN，FIN：用于连接的创建和拆除，RST表示连接重置，SYN表示建立连接，FIN表示关闭连接
接收窗口：用于流量控制，表示接收方愿意接受的字节数量
因特网检验和：用于差错检验
紧急数据指针：指出紧急数据的最后一个字节
3.5.4 可靠数据传输
TCP在IP不可靠的尽力而为服务商创建里一种可靠数据传输服务。
TCP保证从接收缓存中都取出来的数据都是无损坏，无间隔，非冗余，按序的数据流。
一些有趣的情况
第一种情况：
A的报文段序号是92，向B发送了8个字节，那么B应该向A传输ACK（100）表示100以前的报文段收到了，但是B的确认报文丢了，那么A就以为B没收到，所以A就又重现发送了一边数据，造成了数据冗余。
第二种情况：
A连续发送两个报文段给B，第一个报文段序号是92，发送了8个字节，第二个报文段序号是100，发送了20个字节，都完好无损的到达了B，那么第一个报文段的确认号应该是100，第二个应该是120，假设两个回传的确认报文都超时了，A就以为B没收到，所以重传，当A重传序号92的报文段并重启定时器，此时第二个报文（120）的确认报文到了，那么第二个报文就不会被重传。
第三种情况：
和第二种情况一样，在准备重传的时候，第二个报文的确认报文到了，那么两个报文都不会被重传。
超时间隔加倍
实际上就是超时之后，扩大了确认超时的限制。
快速重传
像前面说到的，如果等不到确认报文才开始准备重传，这样会大大增加时延。
快速重传采取的判断丢包的措施是：
如果接收方收到三个冗余ACK（N）即判断丢包了，就立即重传第一个没被确认的报文。
原因：假设A向B发送 n – 1, n, n + 1, n + 2，并且已经收到n – 1
不丢包的情况：
B接收报文的顺序有以下可能：
n – 1, n, n + 1, n + 2;
A收到1次ACK（n）；
n – 1, n, n + 1, n + 2;
A收到1次ACK（n）；
n – 1, n + 1, n, n + 2
A收到两次ACK（n）；
n – 1, n + 1, n + 2, n
A收到三次ACK（n）；
n – 1, n + 2, n, n + 1
A收到两次ACK（n）；
n – 1, n + 2, n + 1, n
A收到三次ACK（n）;
抛去第一种按序到达，乱序到达并且收到3次ACK（n）的概率是2 / 5 = 40%
然后是丢包的情况：
不管什么顺序到达，都会收到3次ACK（n），概率是100%；
虽然收到三次ACK（n）不一定是丢包造成的，但是丢包一定会收到三次ACK（n），两次可能是乱序造成的，三次可能是丢包造成的，四次更可能是丢包造成的但是时延太多，所以就取三次。
是回退N步（GBK）还是选择重传（SR）：
TCP作为GBK和SR的混合体，视情况选择两种协议
3.5.5流量控制
接收方维护一个接收窗口（rwnd）的变量来提供流量控制。
假设A通过一条TCP连接，向B发送一个大文件，那么B会为此次连接分配一个缓存，用RcvBuffer表示。
定义两个变量：
LastByteRead：表示应用程序从缓存中读取的最后一个字节的编号
LastByteRcvd：表示接收到数据的最后一个编号
灰色：表示已经读取的部分
深灰色：表示已经缓存，但是没有读取的元素
那么LastByteRead就是A所在的位置，LastByteRcvd就是B所在的位置。
由于TCP不允许缓存溢出，所以LastByteRcvd – LastByteRead <= RcvBuffer。接收窗口那么就只能接收剩余空间了，rwnd <= RcvBuffer – (LastByteRcvd – LastByteRead)。
因此rwnd是进行动态维护的。
还有一个小问题：
假设B的缓存已经满了，即rwnd = 0，所以B的应用程序要清空缓存，但是A并
不知道B有了新的缓存了，所以不会再发送数据，就造成了拥塞。为了解决这个问题，
TCP规范中要求：当主机B接收窗口为0的时候，主机A继续发送一个只含1个字节 的报文段，这个字节被B接收，并清空缓存。
UDP是不提供流量控制的，UDP通常将数据添加到相应套接字“前面”的一个有限大小的缓存中，如果进程读取的不够快，那么缓存就会溢出，并且将丢失报文段。
3.5.6TCP连接
三次握手建立连接：
A想向B传输可靠数据，所以要向B建立一条TCP连接。
- A向B发送一个特殊的TCP报文，SYN字段被置1表示要建立连接，称为SYN报文段，然后随机选择一个初始序列号（client_isn），放在SYN报文段的序号字段中。封装到IP数据报中，并发送给B。
- B收到来自A的SYN报文段，为TCP分配缓存和变量，并向A发送SYN报文，确认号为client_isn + 1 ，并且随机选择一个初始序列号（server_isn）放到SYN报文段的序列号字段。
注意前两次报文都是不携带应用数据的。
3. A收到B的确认报文（，此时已经建立连接），A为TCP分配缓存和变量，然后再给B发送一个报文，SYN标志位置0，确认字段为server_isn + 1。
客户端TCP状态序列：
初始TCP客户端处于CLOSED状态。
打开连接：
①：客户的应用程序发起一个新的TCP连接，引起客户中的TCP向服务器中的TCP发送一个SYN报文段，然后客户端进入SYN_SENT状态
②：收到服务器发来的ACK确认报文段之后进入ESTABLISHED状态（建立连接），此时TCP客户就能发送和接受包含有效载荷数据的TCP报文段了
关闭连接：
③：客户端TCP发送一个带有FIN标置为1的报文段，客户端进入FIN_WAIT_1状态。
④：客户端收到服务器发送的ACK确认报文段，客户端进入FIN_WAIT_2状态。
⑤：当客户端处于FIN_WAIT_2状态时，客户端等待服务器发送的FIN报文段，收到FIN报文段，确认后，并进入TIME_WAIT。
⑥：如果ACK报文丢失，那么TIME_WAIT状态会使TCP客户端重传最后的确认报文段
最后连接正式关闭，客户端所有资源被释放。
为什么要三次握手，两次已经建立连接了，为什么还要第三次？
谢仁希《计算机网络》看到的，为了防止已经失效的连接请求报文突然传到服务端造成错误，例如一个第一次握手的报文因为拥塞或者各种原因超时了，即发送端发送了另外的请求报文，那么超时的这个报文就失效了，如果这个报文又传到了服务端，如果只经过两次握手的话，那么就可以建立连接，但是这个连接是不需要的，所以就造成了浪费。
四次挥手释放连接：
- 首先发送方给接收方发送报文并且FIN置1。
- 当接收方收到报文，返回ACK确认报文。
- 接收方再发送一个报文FIN置1
- 接收方收到发送方的ACK确认报文
- 用于此次连接的所有资源被释放
服务器端TCO状态序列：
建立连接：
① ：服务器应用程序创建一个监听套接字，进入LISTEN状态
② ：接收SYN并且发送SYN&ACK进入SYN_RVCD的状态
③ ：接收ACK，等待发送方的数据，进入ESTABLISHED状态
释放链接：
④ ：接收FIN发送ACK，进入CLOSE_WAIT状态
⑤ ：发送FIN，进入LAST_ACK状态
⑥ ：接收ACK不发送，关闭连接
为什么进行四次挥手？
TCP是双工通信，一方收到FIN报文的时候，只是说明没有接收的报文了，还是可以发送的，一方发送了FIN报文，处于FIN_wait1状态，但收到对方确认的ACK报文的时候进入FIN_wait2状态，此时处于半断开。因为是双工通信，所以可能一方想断开，但是另一方还有数据要传输，要等一会在断开，所以进行四次挥手。
