1。TCP传输控制协议：
报头：
建立连接：三次握手
1。TCP服务器进程先创建传输控制块TCB, 时刻准备接受客户端进程的连接请求, 此时服务器就进入了 LISTEN（监听）状态
2。TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文，此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定, SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3。TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据, 但是同样要消耗一个序号。
4。TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1，确认序号是 y+1，自己的序列号是 x+1.
5。此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。
断开连接：四次挥手
1。客户端进程发出连接释放报文，并且停止发送数据。
释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2。服务器收到连接释放报文，发出确认报文，ACK=1，确认序号为 u+1，并且带上自己的序列号seq=v，此时服务端就进入了CLOSE-WAIT（关闭等待）状态。
TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3。客户端收到服务器的确认请求后，此时客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最终数据）
4。服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，确认序号为v+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5。客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，确认序号为w+1，而自己的序列号是u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6。服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么要三次握手和四次挥手？
自己通过收到的回应来确保对方收到了自己的消息。
形象的三次握手：（打电话场景）
1。客：你好？（客：它有没有听见我的声音啊？服：这谁啊？）
2。服：你好！（服：客户能听见吗？喂喂？？客：原来没死所）
3。客：哦哦原来你在啊！......噼里啪啦......（服：哦哦它听见了，那么开始接受数据）
形象的四次挥手：（打电话场景）
1。客：好了我说完了。（客：它晓得我不说了吗？服：哦它说完了）
2。服：那你闭嘴吧。......（客：明知道我不说了它还噼里啪啦）
3。服：好了我也说完了。（服：它晓得了不？客：终于不说了）
4。客：我晓得了拜拜。（客：我说我晓得了它听到没有啊？服：啥子态度！挂断）此时客户端处于TIME_WAIT状态
5。2×MSL之后（客：好嘛，它没有问说明它晓得了。挂断）
确认应答：
每个字节都有自己的序号，每一个数据包发送之后都会有回应，发送端可以通过回应的编号知道接收端收到了哪些数据包。
超时重传：
如果在特定的时间内没有收到确认应答的消息，就重传数据包，并且TCP是可以根据序号判断哪些 数据包是重复的，可以去重复。(但是这种方式太慢了，不适用）
滑动窗口：
窗口：允许不接收确认应答就可以发送数据的最大值。
滑动窗口：确认应答之后这个窗口就会向前滑动，操作系统会有一个缓冲区来记录哪些数据还没有发送，只有收到确认应答的数据才可以从缓冲区中去掉。
快重传：
在滑动窗口的基础上，如果发送端连续接受到3个相同的确认应答，那么重传接收端需要的数据。
因为有可能是因为网络拥塞导致接收端延迟收到数据包的。而接收端如果没有收到某确认应答，不重传，因为可能是确认应答丢失，可以通过后面序号的确认应答确认接收端已经收到数据包。
流量控制：
如果接收端接收太慢，就缩小窗口大小，发送端收到信息之后减慢发送速度，如果接收端缓冲区满了，就关闭窗口，发送端定期发送探测数据包（因为窗口更新通知可能丢失，所以探测包表示发送端没有收到窗口更新通知），如果收到窗口更新通知则继续发送。
拥塞控制：
判断网络拥塞：少量丢包就重传，大量丢包就是网络拥塞。
控制：
慢启动：
先发送少量数据包，收到回应之后加大数据包的发送量，指数级增长，达到阈值之后按线性方式增长，发生网络拥塞之后重新慢开始并且阈值减小。
延迟应答：
因为窗口是缓慢增大的，延迟一点点应答可以在应答的数据包中看到自己的窗口大小比较大，这样发送端发送数据就会快一点。
总结：
保证可靠性的机制：
序列号
校验和
确认应答
超时重传
流量控制
拥塞控制
提高性能的机制：
滑动窗口
快重传
延迟应答
计时器：
TIME_WAIT
超时重传定时器
保活定时器
和UDP对比：
TCP可靠连接，主要用于可靠的文件传输上。
UDP不可靠连接，主要用于高速传输和实时性要求高的场景。
