目录
一、初步认识
二、TCP协议格式
2.1 初识协议格式
2.2 序号与确认序号
2.3 16位窗口大小
2.4 六个标志位
三、确认应答机制
四、超时重传机制
五、连接管理机制
5.1 三次挥手
5.2 四次挥手
六、流量控制
七、滑动窗口
八、拥塞控制
九、延迟应答
十、捎带应答
十一、面向字节流
十二、粘包问题
十三、TCP异常情况
十四、TCP小结
TCP全称"传输控制协议"（Transmission Control Protocol），是如今互联网应用最为广泛的传输层协议
网络通信存在不可靠性
如今大部分计算机都基于冯诺依曼体系结构
虽然输入设备、输出设备、内存、CPU等都在一台机器上，但各个硬件设备彼此独立。若它们之间要进行数据交互，就必须要进行通信，因此这几个设备实际是用"线"连接起来的，其中连接内存和外设之间的"线"是IO总线，而连接内存和CPU之间的"线"被称为系统总线。由于这几个硬件设备都在同一台机器上，因此这里传输数据的"线"很短，传输数据时出现错误的概率也较低
但若要进行通信的各个设备相隔千里，那么连接各个设备的"线"就会变得很长，传输数据时出现错误的概率也会大幅增高，此时要保证传输到对端的数据无误，就须引入可靠性
注意：单独的一台计算机可以看作一个小型网络，计算机上的各种硬件设备之间实际也是在进行数据通信，并且在通信时也必须遵守各自的通信协议，只不过更多是描述一些数据的含义
UDP协议存在的合理性
TCP协议是一种可靠的传输协议，使用TCP协议能够在一定程度上保证数据传输时的可靠性，而UDP协议是一种不可靠的传输协议，那这种不可靠的协议存在有什么意义呢？
不可靠和可靠仅是中性词，描述的是协议的特点，并没有贬义：
UDP和TCP没有谁好，只有谁合适，网络通信时采用TCP还是UDP完全取决于上层的应用场景。若应用场景严格要求数据在传输过程中的可靠性，那么就必须采用TCP协议；若应用场景允许数据传输出现少量丢包，那么优先选择UDP协议，因为UDP协议更为简单、轻量
TCP报头中各个字段的含义如下：
TCP报头中的6位标志位：
TCP报头在内核当中本质是一个位段类型，给数据封装TCP报头时，实际上就是用该位段类型定义一个变量，然后填充TCP报头中的各个属性字段，最后将这个TCP报头拷贝到数据的首部，至此便完成了TCP报头的封装
TCP如何将报头与有效载荷进行分离？
当TCP从底层获取到一个报文后，报文的前20个字节是TCP的基本报头，并且这20字节中包含了4位首部长度。因此TCP是如下分离报头与有效载荷的：
注意：
TCP如何将有效载荷交付给上层？
应用层的每一个网络进程都绑定了一个端口号。服务端进程显示绑定端口号；客户端进程由系统动态绑定端口号。而TCP的报头中涵盖了目的端口号，因此TCP可以提取出报头中的目的端口号，找到对应的应用层进程，进而将有效载荷交给对应的应用层进程进行处理
注意：内核中用哈希的方式维护了端口号与进程ID之间的映射关系，因此传输层可以通过端口号快速找到其对应的进程ID，进而找到对应的应用层进程
对于可靠的认识
在进行网络通信时，一方发出的数据后不能保证该数据能够成功被对端收到，因为数据在传输过程中可能会出现各种错误，只有收到对端主机发来的响应消息后，该主机才能保证上一次发送的数据被对端可靠的收到了（只有历史数据可靠）
TCP要保证的是双方通信的可靠性，虽然此时主机A能够保证上一次发送的数据被主机B可靠的收到了，但主机B也需要保证发送给主机A的响应数据被主机A可靠的收到了。因此主机A在收到了主机B的响应消息后，还需要对该响应数据进行响应，但此时又需要保证主机A发送的响应数据的可靠性，这样就陷入死循环
严格意义上来说，互联网通信中不存在百分之百的可靠性，因为双方通信时总有最新的一条消息得不到响应。但实际没有必要保证所有消息的可靠性，只要保证双方通信时发送的每一个核心数据都有对应的响应即可。
对于一些无关紧要的数据（如响应数据），没有必要保证它的可靠性。因为对端若没有收到这个响应数据，会判定上一次发送的报文丢失了，此时对端将上一次发送的数据进行重传即可
这种策略在TCP中被称为确认应答机制。确认应答机制不是保证双方通信的全部消息的可靠性，而是只要一方收到了另一方的应答消息，就说明上一次发送的数据被另一方可靠的收到了
32位序号
若双方在进行数据通信时，只有收到了上一次发送数据的响应才能发下一个数据，那么此时双方的通信过程就是串行的，效率较低
因此双方在进行网络通信时，允许一方向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，这样也就能保证这些报文被对方收到
但在连续发送多个报文时，各个报文在进行网络传输时选择的路径可能不同，因此这些报文到达对端主机的先后顺序可能和发送报文的顺序不同。但报文有序也是可靠性的一种，因此TCP报头中的32位序号的作用之一就是用来保证报文的有序性
TCP将发送出去的每个字节数据都进行了编号，这个编号就是序列号：
此时接收端收到了这三个TCP报文后，就可根据TCP报头中的32位序列号对这三个报文进行排序（该动作在传输层进行），重排后将其放入TCP的接收缓冲区中，此时接收端接收报文的顺序就与发送端发送报文的顺序一致了
接收端在进行报文重排时，可以根据当前报文的32位序号与其有效载荷的字节数，进而确定下一个报文对应的序号
32位确认序号
当主机B收到主机A发送过来的32位序号为1的报文时，由于该报文中包含1000字节的数据。主机B已经收到序列号为1-1000的字节数据，于是主机B发给主机A的响应数据的报头中的32位确认序号的值就填成1001
注意：响应数据与其他数据相同，也是完整的TCP报文。该报文可能不携带有效载荷，但至少具有完整报头
如何处理报文丢失？
主机A发送了三个报文给主机B，其中每个报文的大小都是1000字节，这三个报文的32位序号分别是1、1001、2001。若这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了1-1000和2001-3000的字节数据。此时主机B在对主机A进行响应时，其响应报头中的32位确认序号填的就是1001，告诉主机A下次发送数据时应从序列号为1001的字节数据开始进行发送
此时主机B在给主机A响应时，其32位确认序号不能填3001，因为1001-2000是在3001之前的，若直接给主机A响应3001，就说明序列号在3001之前的字节数据全都收到了。因此主机B只能给主机A响应1001，当主机A收到该确认序号后就会判定序号为1001的报文丢包了，此时主机A就可以选择进行重传
因此发送端可以根据对端发来的确认序号，来判断是报文是否在传输过程中丢失
为什么要用两套序号机制？
若通信双方只有一端发送数据，另一端接收数据，那么只用一套序号即可
但TCP并没有这么做，根本原因就是因为TCP是全双工的，双方可能都想给对方发送消息
因此进行TCP通信时，双方都需要有确认应答机制，此时一套序号就无法满足需求了，因此TCP报头中出现了两套序号
总结
TCP存在接收缓冲区和发送缓冲区
TCP本身是具有接收缓冲区和发送缓冲区的。接收缓冲区用来暂时保存接收到的数据；发送缓冲区用来暂时保存还未发送的数据。这两个缓冲区都在TCP传输层内部实现
当数据写入到TCP的发送缓冲区后，对应的write/send函数（本质上是拷贝函数）就可以返回了，至于发送缓冲区中的数据具体什么时候发，怎么发等问题实际都是由TCP决定的。之所以称TCP为传输控制协议，就是因为最终数据的发送和接收方式、时间，以及传输数据时遇到的各种问题如何解决，都是由TCP自行决定的，用户只需要将数据拷贝到TCP的发送缓冲区，以及从TCP的接收缓冲区中读取数据即可
TCP的发送缓冲区和接收缓冲区存在的意义
经典的生产者消费者模型：
窗口大小
当发送端要将数据发送给对端时，本质是把自己发送缓冲区中的数据发送到对端的接收缓冲区中。但缓冲区大小是有限的，若接收端处理数据的速度小于发送端发送数据的速度，那么总有一个时刻接收端的接收缓冲区会被打满，这时发送端再发送数据过来就会造成数据被迫被丢弃，进而引起丢包重传等一系列的连锁反应（浪费资源）
因此TCP报头中就有了16位窗口大小，这个16位窗口大小中填的是自身接收缓冲区中剩余空间的大小，即当前主机接收数据的能力
接收端在对发送端发来的数据进行响应时，就可以通过16位窗口大小告知发送端自己当前接收缓冲区剩余空间的大小，此时发送端就可以根据这个窗口大小字段来调整自己发送数据的速度
标志位存在的意义
TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文、断开连接时发送的断开连接的报文等。收到不同种类的报文时需要对应执行动作，如正常通信的报文需要放到接收缓冲区中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作
不同种类的报文对应的是不同的处理逻辑，所以要能够区分报文的种类。TCP就是使用报头中的六个标志字段进行区分的，这六个标志位都只占一个bit位
SYN
ACK
FIN
URG
双方在进行网络通信的时候，由于TCP是保证数据按序到达的，TCP通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中时是有序的，对端上层在从接收缓冲区读取数据时也是按顺序读取的。但是有时候发送端可能发送了一些"紧急数据"，这些数据需要让对方上层优先提取读取
此时就需要URG标志位，以及TCP报头中的16位紧急指针
recv函数的第四个参数flags有一个MSG_OOB的选项可供设置，其中OOB是带外数据（out-of-band）的简称，带外数据就是一些比较重要的数据，因此上层若想读取紧急数据，就可以在使用recv函数进行读取，并设置MSG_OOB选项
send函数的第四个参数flags也提供了MSG_OOB的选项，上层若想发送紧急数据，就可以使用send函数进行写入，并设置MSG_OOB选项
PSH
报文中的PSH被设置为1，是在催促对方尽快将接收缓冲区中的数据交付给上层，即使接收缓冲区中的数据还没到达所指定的"水位线"
当使用read/recv从缓冲区中读取数据时，若缓冲区中有数据read/recv函数就能够读到数据进行返回，而若缓冲区当中没有数据，那么此时read/recv函数就会阻塞，直到当缓冲区中有数据时才会读取到数据进行返回。实际这种说法是不太准确的，其实接收缓冲区和发送缓冲区都有一个水位线的概念
若接收缓冲区中有一点数据就让read/recv函数读取返回了，此时read/recv就会频繁的进行读取和返回，进而影响读取数据的效率（在内核态和用户态之间切换有成本）。因此不是接收缓冲区中只要有数据，调用read/recv函数时就能读取到数据进行返回，而是当缓冲区中的数据量达到一定量时（超过水位线）才能进行读取。这就是为什么使用read/recv函数读取数据时，期望读取的字节数和实际读取的字节数不一定是吻合的
RST
报文中的RST被设置为1，表示需要让对方重新建立连接
在通信双方在连接未建立好的情况下，一方向另一方发数据，此时另一方发送的响应报文中的RST标志位就会被置1，表示要求对方重新建立连接。在双方建立好连接进行正常通信时，若通信中途发现之前建立好的连接出现了异常也会要求重新建立连接
TCP保证可靠性的机制之一就是确认应答机制
确认应答机制就是由TCP报头中的32位序号和32位确认序号来保证的。确认应答机制不是保证双方通信的全部消息的可靠性，而是通过收到对方的应答消息，来保证曾经发送给对方的某些消息被对方可靠的收到了
TCP将每个字节的数据都进行编号
TCP是面向字节流的，可以将TCP的发送缓冲区和接收缓冲区都想象成一个字符数组
双方在进行网络通信时，发送方发出去的数据在一个特定的事件间隔内若得不到对方的应答，此时发送方就会进行数据重发
TCP保证双方通信的可靠性，一部分是通过TCP的协议报头体现的，还有一部分是通过实现TCP的代码逻辑体现的。如超时重传机制就是发送方在发送数据后开启了一个定时器，若是在这个时间内没有收到刚才发送数据的确认应答报文，则会对该报文进行重传，这就是通过TCP的代码逻辑实现的，在TCP报头中是体现不出来的
丢包的多种情况
丢包有多种情况，一种是发送的数据报文丢失了，此时发送端在一定时间内收不到对应的响应报文，就会进行超时重传
一种情况是对方发来的响应报文丢包了，此时发送端也会因为收不到对应的响应报文（以为发送失败），而进行超时重传
超时重传的等待时间
超时重传的时间不能设置的太长也不能设置的太短
因此超时重传的时间一定要是合理的，最理想的情况就是找到一个最小的时间，保证"确认应答一定能在这个时间内返回"。但这个时间的长短，是与网络环境有关的。网好的时候重传的时间设置的短一点，网卡的时候重传的时间设置的长一点，即超时重传设置的等待时间一定是上下浮动的，不可能是固定的某个值
TCP为了保证无论在任何环境下都能有比较高性能的通信，动态计算这个最大超时时间
TCP面向连接
TCP的各种可靠性机制都不是从主机到主机的，而是基于连接的，与连接是强相关的。如一台服务器启动后有多个客户端访问，若TCP不是基于连接的，也意味着服务器端只有一个接收缓冲区，此时各个客户端发来的数据都会拷贝到这个接收缓冲区中，此时这些数据就会互相干扰
在进行TCP通信之前需要先建立连接，就是因为TCP的各种可靠性保证都是基于连接的，要保证传输数据的可靠性的前提就是先建立好连接
操作系统对连接的管理
面向连接是TCP可靠性的一种，只有在通信建立好连接才会有各种可靠性的保证，而一台机器上可能会存在大量的连接，此时操作系统就得对这些连接进行管理。
操作系统在管理这些连接时需要"先描述，再组织"，在操作系统中一定有一个描述连接的结构体，该结构体中包含了连接的各种属性字段，所有定义出来的连接结构体都会以某种数据结构组织起来，此时操作系统对连接的管理就变成了对该数据结构的增删查改
建立连接，就是在操作系统中用该结构体定义一个结构体变量，然后填充连接的各种属性字段，最后将其插入到管理连接的数据结构中即可；断开连接，就是将某个连接从管理连接的数据结构中删除，释放该连接曾经占用的各种资源。因此连接的管理也是有成本的，这个成本就是管理连接结构体的时间成本，以及存储连接结构体的空间成本
双方在进行TCP通信之前需先建立连接，建立连接的过程被称为三次握手
以服务器和客户端为例，当客户端想要与服务器进行通信时，需要先与服务器建立连接，此时客户端作为主动方会先向服务器发送连接建立请求，然后双方TCP在底层会自动进行三次握手
客户端向服务器发起的连接建立请求，是请求建立从客户端到服务器方向的通信连接，而TCP是全双工通信，因此服务器在收到客户端发来的连接建立请求后，服务器也需向客户端发起连接建立请求，请求建立从服务器到客户端方法的通信连接
为什么是三次握手？而不是一次、两次、四次？
连接建立并不是百分之百成功的，通信双方在进行三次握手时，其中前两次握手能够保证被对方收到，因为前两次握手都有对应的下一次握手对其进行响应（没有响应则触发重发机制），但第三次握手是没有对应的响应报文的，若第三次握手时客户端发送的ACK报文丢失了，那么连接建立就会失败
虽然客户端发起第三次握手后就完成了三次握手，但服务器却没有收到客户端发来的第三次握手，此时服务器端就不会建立对应的连接结构体。所以建立连接时不管采用几次握手，最后一次握手的可靠性都是不能保证的
既然连接的建立都不是百分之百成功的，因此建立连接时具体采用几次握手的依据，实际是看几次握手时的优点更多
三次握手是验证双方信道通畅的最小次数：
三次握手能够保证连接建立时的异常连接挂在客户端（风险转移）：
三次握手时的状态变化
三次握手时的状态变化如下：
至此三次握手结束，双方可以开始进行正常数据通信了
套接字和三次握手之间的关系
四次挥手的过程
双方维护连接都是需要成本的，因此当双方TCP通信结束之后就需要断开连接，断开连接的这个过程被称为四次挥手
以服务器和客户端为例，当客户端与服务器通信结束后，需断开连接，就需进行四次挥手
为什么是四次挥手？
由于TCP是全双工的，建立连接的时候需要建立双方的连接，断开连接时也同样如此。在断开连接时不仅要断开从客户端到服务器方向的通信信道，也要断开从服务器到客户端的通信信道，其中每两次挥手对应就是关闭一个方向的通信信道，因此断开连接时需要进行四次挥手
某些情况下可能是三次挥手，第二次挥手与第三次挥手合并为一次（有些文章说不行，其实是可以合并的，只不过有条件，看下面的链接）
四次挥手中的第二次和第三次挥手在某些情况下不能合并在一起，因为第三次握手是服务器端想要与客户端断开连接时发给客户端的请求，而当服务器收到客户端断开连接的请求并响应后，不一定会马上发起第三次挥手，因为服务器可能还有某些数据要发送给客户端，只有当服务器端将这些数据发送完后才会向客户端发起第三次挥手
(141条消息) 我问老大：TCP 四次挥手，可以变成三次吗？_四次握手可以变三次-CSDN博客
https://blog.csdn.net/chenxuyuana/article/details/126558893
四次挥手的状态变化
套接字与四次挥手之间的关系
CLOSE_WAIT
TIME_WAIT
若客户端在发出第四次挥手后立即进入CLOSED状态，此时服务器虽然进行了超时重传，但已经得不到客户端的响应了，因为客户端已经将连接关闭了
服务器在经过若干次超时重发后得不到响应，最终也一定会将对应的连接关闭，但在服务器进行超时重传期间并且维护这条废弃的连接，这对服务器非常不友好
为了避免这种情况，因此客户端在四次挥手后没有立即进入CLOSED状态，而是进入到了TIME_WAIT状态进行等待，此时要是第四次挥手的报文丢包了，客户端也能收到服务器重发的报文然后进行响应
TIME_WAIT状态存在的必要性：
TIME_WAIT的等待时长是多少？
TIME_WAIT的等待时长既不能太长也不能太短
太长会让等待方维持一个较长的时间的TIME_WAIT状态，在这个时间内等待方也需要花费成本来维护这个连接，浪费资源。太短可能没有达到最初目的，没有保证ACK被对方较大概率收到，也没有保证数据在网络中消散，此时TIME_WAIT就没有意义了。TCP协议规定，主动关闭连接的一方在四次挥手后要处于TIME_WAIT状态，等待两个MSL（报文最大生存时间）的时间才能进入CLOSED状态
MSL在RFC1122中规定为两分钟，但是各个操作系统的实现不同，如在Centos7上默认配置的值是60s。可以通过cat /proc/sys/net/ipv4/tcp_fin_timeout命令来查看MSL
TIME_WAIT的等待时长设置为两个MSL的原因：
TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度
接收端处理数据的速度是有限的，若发送端发的太快，导致接收端的缓冲区被打满，此时发送端继续发送数据，就会造成丢包，进而引起重传、资源浪费等一系列连锁反应
因此接收端可以将自己接收数据的能力告知发送端，让发送端控制发送数据的速度
当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据
16为数字最大表示65535，那TCP窗口最大就是65535吗？
理论上是这样的，但实际上TCP报头中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的
第一次向对方发送数据时如何得知对方的窗口大小？
双方在进行TCP通信之前需先进行三次握手建立连接，而双方在握手时除了验证双方信道是否通畅以外，还进行其他信息的交互，其中就包括告知对方自己的接收能力，因此在双方还没有正式开始通信之前就已经知道了对方接收数据能力，所以双方在发送数据时是不会出现缓冲区溢出的
连续发送多个数据
每次仅发送一个数据段（多次IO）效率太低，双方在进行TCP通信时可以一次向对方发送多条数据，等待多个响应的时间重叠，提高通信效率
注意：虽然双方在进行TCP通信时可以一次向对方发送大量的报文，但不能将发送缓冲区中的数据全部一次发送给对端，在发送数据时还需考虑对方的接收能力
滑动窗口
发送方可以一次发送多个报文给对方，此时也就意味着发送出去的这部分报文中有相当一部分数据是暂时没有收到应答的
发送缓冲区中的数据分为三部分：
滑动窗口描述的是：发送方不用等待ACK一次所能发送的数据最大量
滑动窗口存在的最大意义就是可以提高发送数据的效率：
当发送方发送出去的数据段陆续收到对应的ACK时，滑动窗口左边界向右移动，此时收到ACK的数据段就被归置到滑动窗口左侧。再根据当前滑动窗口的大小决定，滑动窗口右边界是否向右移动
TCP的重传机制要求暂时保存发出但未收到确认的数据，而这部分数据实际就位于滑动窗口中，只有滑动窗口左侧的数据才是可以被覆盖或删除的，因为这部分数据才是发送并被对方可靠的收到了，所以滑动窗口除了支持大量发送以外，也支持TCP的重传机制
滑动窗口一定会整体右移吗？
滑动窗口不一定会整体右移的，假设对方已经收到了1001-2000的数据段并进行了响应，但对方上层一直不从接收缓冲区中读取数据，此时对方的16位窗口大小就由4000变为了3000
当发送端收到对方的响应序号为2001时，1001-2000的数据段依然保存，但此时由于对方的接收能力变为了3000，滑动窗口的大小也变为3000，右侧不能继续向右进行扩展
如何实现滑动窗口
TCP接收和发送缓冲区都被看作一个字符数组，而滑动窗口可以看作是两个指针（下标）限定的一个范围，比如用start指向滑动窗口的左侧，end指向的是滑动窗口的右侧，此时在start和end区间范围内的就可以被称为滑动窗口
当发送端收到对方的响应时，若响应中的确认序号为x，16位窗口大小为win，此时就可以将start更新为x，而将end更新为start + win
滑动窗口中的数据一定都没有被对方收到吗？
滑动窗口中的数据是可以暂时不用收到对方确认的数据，而不是说滑动窗口中的数据一定都没有被对方收到，滑动窗口中可能有一部分数据已经被对方收到了，但可能因为滑动窗口中一部分数据，在传输过程中出现了丢包等情况，导致后面已经被对方收到的数据得不到响应
如图中的1001-2000的数据包若在传输过程中丢包了，此时虽然2001-5000的数据都被对方收到了，此时对方发来的确认序号是1001，当发送端补发了1001-2000的数据包后，对方发来的确认序号就会变为5001，此时发送缓冲区向右移动
丢包问题
情况一： 数据包已经抵达，ACK响应丢包
在发送端连续发送多个报文数据时，部分ACK丢包并不要紧，此时可以通过后续的ACK进行确认
如图中2001-3000和4001-5000的数据包对应的ACK丢失了，但发送端收到了最后5001-6000数据包的响应，此时发送端就知道2001-3000和4001-5000的数据包实际上被接收端收到了的，因为确认序号为6001的含义就是序号为6000以前的字节数据都收到了，下一次从序号为6001的字节数据开始发送
情况二： 数据包丢包
快重传需要在大量的数据重传和个别的数据重传之间做平衡，上述例子中发送端并不知道是否仅有1001-2000这个数据包丢了，当发送端重复收到确认序号为1001的响应报文时，理论上发送端应该将1001-7000的数据全部进行重传，但这样可能会导致大量数据被重复传送，所以发送端可以尝试先把1001-2000的数据包进行重发，然后根据重发后的得到的确认序号继续决定是否需要重发其它数据包
快重传 VS 超时重传
为什么会有拥塞控制？
两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发。但若双方在通信时出现了大量丢包，此时就不能认为是正常现象了
TCP不仅考虑了通信双端主机的问题，同时也考虑了网络的问题。双方网络通信时出现少量的丢包TCP是允许的，但一旦出现大量的丢包，此时TCP就不再认为是双方接收和发送数据的问题，而是判断双方通信信道网络出现了拥塞问题，从而需要进行拥塞控制
如何应对网络拥塞问题？
网络出现大面积瘫痪时，通信双方作为网络中两台小小的主机，看似并没有什么作用，但大部分主机都会使用TCP协议，网络出现问题一定是网络中大部分主机共同作用的结果
拥塞控制
虽然滑动窗口能够高效可靠的发送大量的数据，但在不清楚当前网络状态的情况下，贸然发送大量的数据，可能会引起或加重网络拥塞问题。因此TCP引入了慢启动机制，在刚开始通信时先发少量的数据探路，摸清当前网络状况，再决定按照多大的速度传输数据
每收到一个ACK应答拥塞窗口的值就加一，经过每个传输轮次，拥塞窗口以指数级别进行增长，拥塞窗口的大小变化情况如下：
"慢启动"只是初始时比较慢，越往后增长越快。若拥塞窗口一直以指数的方式进行增长，就可能在短时间内再次导致网络出现拥塞
若接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能较小
注意：延迟应答的目的不是为了保证可靠性，而是留出时间让接收缓冲区中的数据尽可能被上层应用层消费掉，此时在进行ACK响应时窗口大小就更大，从而增大网络吞吐量，减少IO次数，进而提高数据的传输效率
延迟应答机制也有一定限制
延迟应答具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms
捎带应答是TCP通信最常规的机制。当主机A给主机B发送了一条消息，当主机B收到这条消息后需进行ACK应答，但若主机B正好也要给主机A发送消息，此时就不用单独发送一个ACK应答。此时主机B发送的这个报文就可以既包含数据，又包含对收到数据的响应，即捎带应答
捎带应答机制可提高发送数据的效率，此时双方通信时就不用发送单纯的确认报文了，减少网络IO次数
当创建一个TCP的socket时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。
由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：
对于TCP而言，并不关心发送缓冲区中的是什么数据，在TCP看来只是一个个的字节数据，其任务就是将这些数据准确无误的发送到对方的接收缓冲区中就行了，而至于如何解释这些数据完全由上层应用来决定，这就被称为面向字节流
什么是粘包？
如何解决粘包问题
要解决粘包问题，本质就是要明确报文和报文之间的边界。
UDP是否存在粘包问题？
因此UDP是不存在粘包问题的，根本原因是UDP报头中的16位UDP长度记录了UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了，而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界
进程终止
当客户端正常访问服务器时，若客户端进程突然崩溃了，此时建立好的连接会怎么样？
当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。即进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别
机器重启
当客户端正常访问服务器时，若将客户端主机重启，此时建立好的连接会怎么样？
当选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源
机器掉电/网线断开
当客户端正常访问服务器时，若客户端突然掉线了，此时建立好的连接会怎么样？
当客户端掉线后，服务器端在短时间内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的
其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，由TCP实现。应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态
TCP协议复杂的原因是因为TCP既要保证可靠性，同时又尽可能的提高性能。
可靠性：
提高性能：
注意：TCP的这些机制有些能够通过TCP报头体现，但有一些是通过底层代码逻辑体现出来的
TCP定时器
理解传输控制协议
TCP的各种机制实际都没有谈及数据真正的发送，这些都是传输数据的策略。TCP协议是在网络数据传输中做决策的，提供的仅是理论支持，而数据真正的发送实际是由底层的IP和MAC帧完成的
TCP做决策和IP+MAC做执行，将这些统称为通信细节，最终的目的就是为了将数据传输到对端主机。而传输数据的目的是什么则是由应用层决定的。因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式
基于TCP的应用层协议
常见的基于TCP的应用层协议如下：
