TCP（Transmission Control Protocol）传输控制协议，TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立连接。
一、TCP的三次握手和四次挥手
（一）三次握手
第一次握手：客户端TCP首先向服务器端的TCP发送一个特殊的TCP报文段
（SYN报文段），该报文段不包含应用层数据。其中SYN标志位被置为1，客户机随机选择一个初始序号（client_isn）作为报文段序号，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到SYN报文段，并向客户端发送允许连接的报文段（SYNACK报文段），该报文段不包含应用层数据。其中SYN=1，确认号ack=client_isn+1，并且服务器会选择字节的初始序号server_isn作为序号seq，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到SYNACK报文段，向服务器发送确认包ACK，其中SYN=0，ack=server_isn+1,seq=client_isn+1,这样客户端和服务器都进入ESTABLISHED状态。
完成三次握手，两台主机开始传输数据
握手过程传送的包是不包含数据的，但是握手的第三个阶段可以在报文段携带客户到服务器的数据。三次握手完毕，客户和服务器才正式开始传送数据，TCP一旦建立连接，将一直被保持下去，直到通信双方中的任意一方主动关闭连接，断开的过程需要经过“四次挥手”。
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭，这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接，收到一个FIN只意味这这个方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据，首先进行关闭的一方执行主动关闭，而另一方进行被动关闭。主动关闭的一方称为client，被动关闭的一方称为server。
（二）四次挥手
第一次挥手：客户TCP向服务器发送一个特殊TCP报文段，首部标志位FIN=1。客户端进入FIN_WAIT_1状态
第二次挥手：服务器收到报文段，向客户端发送一个确认报文段ACK，服务器进入CLOSE_WAIT状态
客户机收到ACK，不发送任何信息，客户TCP进入FIN_WAIT_2状态。
第三次挥手：紧接着服务器发送自己的终止报文段，其中FIN=1，服务器进入LAST_ACK
第四次挥手：客户端收到报文段，向服务器发送确认报文ACK,，客户进入TIME_WAIT状态。
最后两台主机上用于连接的所有资源都被释放，进入CLOSE状态。
TCP的6种标志位：
SYN（synchronous建立连接）
ACK（acknowledgement确认）
PSH（push传送）
FIN（finish结束）
RST（reset重置）
URG（urgent紧急）
客户端的TCP状态迁移：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务器状态迁移：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE
（三）思考
1）为什么连接的时候是三次握手，关闭的时候是四次挥手
答：这是因为服务器在LISTEN状态下收到建立连接的请求的SYN报文后，将SYN和ACK放在一个报文里发送给客户端，所以是三次，其中SYN是用来同步的，ACK是用来应答的,。但是关闭连接的时候server端收到FIN报文时，仅仅表示对方不再发送数据了但还是可以接收数据，而且server自己也可能有待发送数据，所以server可以立即close，也可以先发送数据给client，再发送FIN给client表示自己同意关闭连接，因此ACK和FIN分开发送所以是四次。
2）为什么不能用两次握手进行连接
答：三次握手的目的是为了防止已经失效的连接请求报文端突然又传到了服务端，因而产生错误，也可以说是为了解决网络中存在延迟的重复分组问题。
情况1:假如client发出一个连接请求，这个请求报文段没有丢失但因为某种原因在网络节点长时间滞留，导致server端在规定时间内没有收到，无法发送确认ACK，此时连接不成功，如果client不再建立连接，过一段时间后，那个延迟的报文段被server接收，server会误认为是client发出的新的请求，这样server就会发出确认，在二次握手模式下，只要server发出确认新的连接就建立了，但是client实际并没有发出请求连接是处于一个CLOSED的状态，不会理会server的确认，不会发送数据给server，那么server就会一直处于等待状态，这样就浪费了大量的资源。
情况2：将情况1改变=一下，假如server接收到延迟失效的请求报文的时候client发出了一个新的请求，但是server会丢弃这个新的请求包，server接收到的SYN序号和client发送的SYN不一致。
3）为什么TIME_WAIT状态需要经过2MSL（最大报文生存时间）才能返回CLOSE状态
答：虽然双方都同意关闭连接了，挥手的4个报文也发送完毕，按理是可以直接回到CLOSED状态了，但是我们要考虑网络不可靠状态，我们无法保证最后发送的ACK报文一定能被对方接收到，所以在对方处于LAST_ACK状态下的SOCKET可能因为超时未收到ACK而重发FIN报文，TIME_WAIT状态的作用就是用来重发可能丢失的报文。
二、TCP协议的实现
接下来从三个方面具体讲解TCP的协议的实现
- TCP如何实现可靠数据传输
- TCP如何实现流量控制
- TCP如何处理网络拥塞
（一）TCP如何实现可靠传输
A向B发送数据包
停止等待协议：
1.无差错无丢包情况A未收到B的确认信息就一直等待，直到A收到确认信息
2.超时重传：超过时间（大于等于一个往返时间）未收到确认消息，A默认重新发送是自动的，无需B告知
3.确认丢失：会丢弃重复的消息
4.确认迟到：会收下迟到的消息，但什么也不做
上面的图显示的是一种确认-重传机制，这种可靠的协议被称为自动重传请求ARQ，通过这种协议实现了在不可靠的网络上实现可靠的通信。
停止等待机制虽然简单但是信道利用率太低,A给B发送信息，只花了TD的时间，其他时间都在等待，这样效率十分低下
显然我们可以让A持续发送而不必没发完一个分组就等待对方确认,这种机制称为流水线传输
流水线传输——连续的ARQ协议
假设发送窗口是5，即代表当A持续发送数据包到5就不能再发送，需要等待，如果收到1的确认，那么窗口移动到6，可以继续发送6这个数据包
累积确认：当B收到数据包1的时候不会马上给A发送确认信息，，而是等待连续收到一组数据包在确认，比如收到1,2，3,4，那么B就会只发送确认信息4。
缺点：如果发送1,2，3,4的时候数据包3缺失，那么3和4都需要重传
以字节为单位的滑动窗口
假设有一个文件有40个字节，有两个主机A和B，A和B建立连接之前产生会话，B告诉A它的接收缓存（接收窗口）是20个字节，那么A就会设置它的发送缓存为20个字节（不能超过20），A第一次发送一个数据包（1，2，3字节），未等到确认继续发送第二第三个数据包1-20，当B确认收到之后会将数据包存进接收缓存中，并返回确认信息告诉A下次继续传输下一个
B确认收到123456，发送确认号7，A将123456删除，并将窗口往后移动
优点：如果在传输过程中有数据包确实，比如78910丢失，11…20没有缺失，那么B会发送选择性确认号SACK=7，让A只需发送丢失的包，而不用再重传1112…20的数据包了。
（二）TCP如何实现流量控制
流量控制：解决通信两端处理速度不一致问题，如果A发送信息给B的速度大于B接受处理的信息，超过B的承载范围，那么B就会告诉A慢一点，让A控制发送的速度，从而达到流量控制的目的。
方法：利用滑动窗口机制
TCP窗口单位是字节不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口数值
（三） TCP如何处理网络拥塞
拥塞控制：在某段时间，网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要优化。
方法
1.慢启动：发送报文段速率的确定，既要根据接收端的接收能力，又要从全局考虑不要使网络发生拥塞，这由接收窗口和拥塞窗口两个状态量确定。接收端窗口（Reciver Window)又称通知窗口（Advertised Window),是接收端根据目前的接收缓存大小所许诺的最新窗口值，是来自接收端的流量控制。拥塞窗口cwnd（Congestion Window)是发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制。
2.拥塞避免:
1）TCP连接初始化，将拥塞窗口设置为1
2）执行慢开始算法，cwind按指数规律增长，知道cwind == ssthress开始执行拥塞避免算法，cwnd按线性规律增长
3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照步骤（2）执行。
3.快速恢复
1）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半，这是为了预防网络发生拥塞。
2）由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，是拥塞窗口的线性增大。
（四）小结
没有拥塞控制的网络很多容易出现死锁，使得端到端之间很少或没有数据能被传输。TCP实现的是一种端到端拥塞控制机制，即：当TCP连接的路径判断不拥塞时，它的传输速率就加性增；当出现丢包时，传输速率就乘性减。这种机制致力于做到每一个通过拥塞链路的TCP连接能平等地共享该链路带宽。
TCP和UDP的区别
- 连接vs无连接： TCP面向连接，UDP是无连接协议
- 可靠性不同：TCP传输可靠，UDP不可靠
- 有序性不同：TCP保证消息的有序性，UDP不提供任何保证，消息到达可能失序
- 数据边界：TCP不保存数据的边界，UDP保证
- 面向对象不同：TCP面向字节流，UDP面向数据包
- 速度不同：TCP慢，UDP快
- 分组开销不同：TCP首部20字节，开销大；UDP只有8字节
- TCP具有流量控制和网络拥塞控制，UDP不能
注意：TCP传输单位称为TCP报文段，UDP传输单位称为用户数据报。 - 实时应用通常以最小的发送速率不希望过分地延迟报文段的传送，能容忍一些数据的丢失会选择UDP
10.TCP占用资源多 ，UDP占用资源少
