计算机网络复习总结2

1.10 介绍一下TCP三次握手。

1. 第一次握手：建立连接，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

1.11 介绍一下TCP的四次挥手。

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

四次挥手过程

（1）客户端向服务器发送FIN控制报文段（首部中的 FIN 比特被置位）；

（2）服务端收到FIN，回复ACK。服务器进入关闭等待状态，发送FIN;

（3）客户端收到FIN，给服务器回复ACK，客户端进入等待状态（进入“等待”，以确保服务器收到ACK真正关闭连接）;

（4）服务端收到ACK，链接关闭。

1.12 为什么需要四次挥手？

TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP是全双工模式，这就意味着，当客户端发出FIN报文段时，只是表示客户端已经没有数据要发送了，客户端告诉服务器，它的数据已经全部发送完毕了；但是，这个时候客户端还是可以接受来自服务端的数据；当服务端返回ACK报文段时，表示它已经知道客户端没有数据发送了，但是服务端还是可以发送数据到客户端的；当服务端也发送了FIN报文段时，这个时候就表示服务端也没有数据要发送了，就会告诉客户端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

简单地说，前 2 次挥手用于关闭一个方向的数据通道，后两次挥手用于关闭另外一个方向的数据通道。

1.13 三次握手为什么要有最后一次ACK？

证明了客户端的接收能力，与服务器端的发送能力。
客户端首先向服务器发送一个连接请求，但是可能这个连接请求走了远路，等了很长时间，服务器都没有收到，那么客户端可能会再次发送，此时服务器端收到并且回复SYN、ACK；在这个时候最先发送的那个连接请求到达服务器，那么服务器会回复一个SYN，ACK；但是客户端表示自己已经收到确认了，并不搭理这个回复，那么服务器可能陷入等待，如果这种情况多了，那么会导致服务器瘫痪，所以要发送第三个确认。

1.14 介绍一下TCP粘包、拆包的机制。

1. TCP粘包和拆包问题

   TCP是一个“流”协议，所谓流，就是没有界限的一长串二进制数据，没有消息保护边界。一方发送的多个报文可能会被合并成一个大的报文进行传输，这就是粘包；也可能发送的一个报文，可能会被拆分成多个小报文，这就是拆包。

2. 产生TCP粘包和拆包的原因

粘包的主要原因：

1. 发送方每次写入数据 < 套接字(Socket)缓冲区大小；
2. 接收方读取套接字(Socket)缓冲区数据不够及时；

半包 的主要原因：

1. 发送方每次写入数据 > 套接字(Socket)缓冲区大小；
2. 发送的数据大于协议的 MTU (Maximum Transmission
   Unit，最大传输单元)，因此必须拆包；

其实我们可以换个角度看待问题：

从收发的角度看，便是一个发送可能被多次接收，多个发送可能被一次接收。
从传输的角度看，便是一个发送可能占用多个传输包，多个发送可能共用一个传输包。

根本原因是：TCP 是流式协议，消息无边界。

扩展资料

UDP会不会产生粘包问题呢？

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

3. 如何处理

如上所述，UDP 之所以不会产生粘包和半包问题，主要是因为消息有边界。因此，我们也可以采取类似的思路处理tcp消息。

1. 改成短连接（不推荐）
   将 TCP 连接改成短连接，一个请求一个短连接。这样建立连接到释放连接之间的消息即为传输的信息，消息也就产生了边界。

优点：十分简单，不需要在我们的应用中做过多修改。
缺点：效率低下，TCP连接和断开都会涉及三次握手以及四次握手，每个消息都会涉及这些过程，十分浪费性能。

2. 封装成帧
   将传输消息封装成帧(Framing)，也就是原本发送消息的单位是缓冲大小，现在换成了帧，这样我们就可以自定义边界了。一般有以下4种方式：

固定长度 （不推荐）
消息长度采用固定长度即可，较短的消息可采用默认值填充。

优点：实现简单。 缺点：有极大的流量浪费，如果传递的消息中大部分都比较短，为了兼容最长的消息可能消息中有很多默认值作为无效的信息传输。

分隔符（消息体较短时，推荐）

使用分隔符作为消息边界，通过获取分隔符将消息切割。

优点：空间使用率高，实现也比较简单。
缺点：是当内容本身出现分割符时需要转义，所以无论是发送还是接受，都需要扫描整个内容做转义处理。

在特殊字符分隔符协议中：
发送方，需要在发送一个报文时，需要在报文尾部添加特殊分割符号;
接收方，在接收到报文时，需要对特殊分隔符进行检测，直到检测到一个完整的报文时，才能进行处理。
在使用特殊字符分隔符协议的时候，需要注意的是，我们选择的特殊字符，一定不能在消息体中出现，否则可能会出现错误的拆包。例如，发送方希望把”12\r\n34”，当成一个完整的报文，如果是按行拆分，那么就会错误的拆分为2个报文。一种解决策略是，发送方对需要发送的内容预先进行base64编码，由于base64编码只包含64个字符：0-9、a-z、A-Z、+、/，我们可以选择这64个字符之外的特殊字符作为分隔符。

3. 专门的 length 字段

这种方式有点类似于Http 请求中的 Content-Length，有一个专门的字段存储消息的长度。作为服务端，接受消息时，先解析固定长度的字段(length字段)获取消息总长度，然后读取后续内容。

优点：精确定位用户数据，内容也不用扫描转义。
缺点：长度理论上有限制，因为长度字段占用字节数为固定值要先定义， 因此限制了传输消息的最大长度。另外如果长度占用字节过多，在传输短消息时，会造成头部信息占比过长，影响传输效率。

消息体较长时，推介用这种方式。

4. 其他方式

其他方式多种多样，比如 JSON 可以看成是使用 { } 是否成对，xml可以看括号是否配对等等。

1.15 介绍一下TCP和UDP的区别。

1. 连接：TCP面向连接的传输层协议，即传输数据之前必须先建立好连接；UDP无连接。

2. 服务对象：TCP点对点的两点间服务，即一条TCP连接只能有两个端点；UDP支持一对一，一对多，多对一，多对多的交互通信。

3. 可靠性：TCP可靠交付：无差错，不丢失，不重复，按序到达；UDP是不可靠的。

4. TCP是面向字节流的，UDP是面向数据报文的

5. TCP协议下双方发送接受缓冲区都有，UDP并无实际意义上的发送缓冲区，但是存在接受缓冲区

6. 拥塞控制/流量控制：有拥塞控制和流量控制保证数据传输的安全性；UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。

7. 报文长度：TCP动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的；UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。

8. 首部开销：TCP首部开销大，首部20个字节；UDP首部开销小，8字节（源端口，目的端口，数据长度，校验和）。

9. 适用场景（由特性决定）：数据完整性需让位于通信实时性，则应该选用TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。

1.16 TCP和UDP对于网络稳定性有什么要求？

1. TCP优缺点

   优点：可靠、稳定

   TCP的可靠体现在TCP在传输数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完之后，还会断开连接用来节约系统资源。

   缺点：慢，效率低，占用系统资源高，易被攻击

   在传递数据之前要先建立连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞机制等都会消耗大量时间，而且要在每台设备上维护所有的传输连接。然而，每个链接都会占用系统的CPU、内存等硬件资源。因为TCP有确认机制、三次握手机制，这些也导致TCP容易被利用，实现DOS、DDOS、CC等攻击。

2. UDP优缺点

   优点：快，比TCP稍安全

   UDP没有TCP拥有的各种机制，是一个无状态的传输协议，所以传递数据非常快，没有TCP的这些机制，被攻击利用的机制就少一些，但是也无法避免被攻击。

   缺点：不可靠，不稳定

   因为没有TCP的那些机制，UDP在传输数据时，如果网络质量不好，就会很容易丢包，造成数据的缺失。

3. 适用场景（网络稳定性要求）

   TCP：当对网络通讯质量有要求时，比如HTTP、HTTPS、FTP等传输文件的协议， POP、SMTP等邮件传输的协议

   UDP：对网络通讯质量要求不高时，要求网络通讯速度要快的场景。

   所以，TCP对网络稳定性要求高，而UDP相对弱一些。

1.17 如何让UDP可靠一些？

1. 为什么需要可靠的UDP

   在弱网（2G、3G、信号不好）环境下，使用 TCP 连接的延迟很高，影响体验。使用 UDP 是很好的解决方案，既然把 UDP 作为弱网里面的 TCP 来使用，就必须保证数据传输能像 TCP 一样可靠。

2. 如何实现可靠的UDP

   UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。关键在于两点，从应用层角度考虑：

   （1）提供超时重传，能避免数据报丢失。

   （2）提供确认序列号，可以对数据报进行确认和排序。

   本端：首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。

   对端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。

扩展资料

已经实现的可靠UDP：

（1）RUDP 可靠数据报传输协议；

（2）RTP 实时传输协议：为数据提供了具有实时特征的端对端传送服务；

Eg：组播或单播网络服务下的交互式视频、音频或模拟数据

（3）UDT：基于UDP的数据传输协议，是一种互联网传输协议；

主要目的是支持高速广域网上的海量数据传输，引入了新的拥塞控制和数据可靠性控制机制（互联网上的标准数据传输协议TCP在高带宽长距离的网络上性能很差）；

UDT是面向连接的双向的应用层协议，同时支持可靠的数据流传输和部分可靠的数据报服务；

应用：高速数据传输，点到点技术(P2P)，防火墙穿透，多媒体数据传输；

1.18 TCP报文首部中序号占多少字节？

序号字段占4个字节（32位）。

TCP首部包括20字节的固定首部部分及长度可变的其他选项，所以TCP首部长度可变。20个字节又分为5部分，每部分4个字节32位，如图中的5行，每行表示32位。

1. 源端口和目的端口字段——各占 2 字节（16位）。端口是传输层与应用层的服务接口。传输层的复用和分用功能都要通过端口才能实现。

2. 序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则**指的是本报文段所发送的数据的第一个字节的序号。**比如分组的第一个数据包由文件的14个字节数据组成，那么该数据包所添加的序号就是1，同理第二个数据包由文件的59个字节数据组成，那么该数据包所添加的序号就是5；

3. 确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。比如接收端收到由文件14个字节数据+TCP首部组成的数据包后，删除首部提取14个字节数据，返回的确认号为5，即告诉发送端下一次应该发送文件的第5个字节及其之后字节组成的数据包过来。

4. 数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远，也就是TCP首部的长度。“数据偏移”的单位是 32 位字（以 4 字节为计算单位），最大1111表示15x4=60个字节，即表示TCP首部最大长度为60个字节，因此“选项”部分最多40个字节。

5. 保留字段——占 6 位，保留为今后使用，但目前应置为 0。

6. 这里的六位二进制位，分别表示不同含义：

   （1）紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。 即URG=1的数据包不用排队直接优先传输。

   （2）同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。即A想与B建立连接，发送过去的第一个数据包（第一次握手）中SYN=1；B返回的数据包（第二次握手）中SYN=1表示同意建立连接。

   （3）确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效。

7. 窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。

8. 检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。

9. 紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。

10. 选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”其他选项有：窗口扩大选项、时间戳选项、选择确认选项（SACK）。

11. 填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

1.19 TCP中的缓存有什么作用？

1. TCP缓冲区是什么

   每个 socket 被创建后，都会分配两个缓冲区，输入缓冲区和输出缓冲区。

2. 缓冲区的意义（作用）

TCP的发送缓冲区是用来缓存应用程序的数据，发送缓冲区的每个字节都有序列号，被应答确认的序列号对应的数据会从发送缓冲区删除掉。

write()/send() 并不立即向网络中传输数据，而是先将数据写入缓冲区中，再由TCP协议将数据从缓冲区发送到目标机器。一旦将数据写入到缓冲区，函数就可以成功返回，不管它们有没有到达目标机器，也不管它们何时被发送到网络，这些都是TCP协议负责的事情。 TCP协议独立于 write()/send() 函数，数据有可能刚被写入缓冲区就发送到网络，也可能在缓冲区中不断积压，多次写入的数据被一次性发送到网络，比如nagle算法，这取决于当时的网络情况、当前线程是否空闲等诸多因素，不由程序员控制。 read()/recv() 函数也是如此，也从输入缓冲区中读取数据，而不是直接从网络中读取。

3. I/O缓冲区特性

   （1）I/O缓冲区在每个TCP套接字中单独存在；

   （2）I/O缓冲区在创建套接字时自动生成；

   （3）即使关闭套接字也会继续传送输出缓冲区中遗留的数据；

   （4）关闭套接字将丢失输入缓冲区中的数据。

   输入输出缓冲区的默认大小一般都是 8K，可以通过 getsockopt() 函数获取：

   //代码实例（缓冲区大小获取） 
   int servSock = socket(PF_INET, SOCK_STREAM, 0); 
   unsigned optVal; 
   int optLen = sizeof(int); 
   getsockopt(servSock, SOL_SOCKET, SO_SNDBUF, (char*)&optVal, &optLen); 
   /*  运行结果：  Buffer length: 8192  */
   1
   2
   3
   4
   5
   6

1.20 说一说TCP是怎么控制流量的？

1. 一般来说，流量控制就是为了让发送方发送数据的速度慢点，要让接收方来得及接收。

2. TCP控制流量的方法

   利用滑动窗口机制就可以实施流量控制。

   原理就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送方将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

   解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

3. TCP的滑动窗口

   为了提高信道的利用率TCP协议不使用停止等待协议，而是使用连续ARQ（Automatic Repeat-reQuest，自动重传请求）协议，意思就是可以连续发出若干个分组然后等待确认，而不是发送一个分组就停止并等待该分组的确认。

   TCP的两端都有发送/接收缓存和发送/接收窗口。TCP的缓存是一个循环队列，其中发送窗口可以用3个指针表示。而发送窗口的大小受TCP数据报中窗口大小的影响，TCP数据报中的窗口大小是接收端通知发送端其还可以接收多少数据，所以发送窗口根据接收的的窗口大小的值动态变化。

   以下的几张图片就帮助理解一下滑动窗口的机制：

注意上图中的3个指针P1、P2、P3！此时接收窗口中接收的数据可能是失序的，但是也先存储在接收缓存之中。发送确认号的时候依然发送31，表示B期望接收的下一个数据报的标示符是31。

如果发送窗口中的数据报都属于已发送但未被确认的话，那么A就不能再继续发送数据，而需要进行等待。

5. 传输效率及Nagle算法

   TCP的数据传输分为交互数据流和成块数据流，交互数据流一般是一些交互式应用程序的命令，所以这些数据很小，而考虑到TCP报头和IP报头的总和就有40字节，如果数据量很小的话，那么网络的利用效率就较低。

   数据传输使用Nagle算法，Nagle算法很简单，就是规定一个TCP连接最多只能有一个未被确认的未完成的小分组。在该分组的确认到达之前不能发送其他的小分组。

   但是也要考虑另一个问题，叫做糊涂窗口综合症。当接收方的缓存已满的时候，交互应用程序一次只从缓存中读取一个字节（这时候缓存中腾出一个字节），然后向发送方发送确认信息，此时发送方再发送一个字节（收到的窗口大小为1），这样网络的效率很低。

   要解决这个问题，可以让接收方等待一段时间，使得接收缓存已有足够的空间容纳一个最长报文段，或者等到接收缓存已有一半的空间。只要这两种情况出现一种，就发送确认报文，同时发送方可以把数据积累成大的报文段发送。

1.21 HTTP2.0中TCP阻塞了怎么办？

HTTP2.0中TCP阻塞了有如下两种方法可以解决：

（1）并发TCP连接（浏览器一个域名采用6-8个TCP连接，并发HTTP请求） （2）域名分片（多个域名，可以建立更多的TCP连接，从而提高HTTP请求的并发）

1. TCP队头阻塞

​TCP数据包是有序传输，中间一个数据包丢失，会等待该数据包重传，造成后面的数据包的阻塞。

2. HTTP队头阻塞

​ http队头阻塞和TCP队头阻塞完全不是一回事。

​ http1.x采用长连接(Connection:keep-alive)，可以在一个TCP请求上，发送多个http请求。

​ 有非管道化和管道化，两种方式。

​ 非管道化，完全串行执行，请求->响应->请求->响应…，后一个请求必须在前一个响应之后发送。

​ 管道化，请求可以并行发出，但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是，没有序号标明顺序，只能串行接收。

​ 管道化请求的致命弱点:

（1）会造成队头阻塞，前一个响应未及时返回，后面的响应被阻塞
（2）请求必须是幂等请求，不能修改资源。因为，意外中断时候，客户端需要把未收到响应的请求重发，非幂等请求，会造成资源破坏。

​ 由于这个原因，目前大部分浏览器和Web服务器，都关闭了管道化，采用非管道化模式。

​ 无论是非管道化还是管道化，都会造成队头阻塞(请求阻塞)。

2. HTTP2方式

http2使用一个域名单，TCP连接发送请求，请求包被二进制分帧，不同请求可以互相穿插，避免了http层面的请求队头阻塞。 但是不能避免TCP层面的队头阻塞。

1.22 TCP如何保证可靠性？

TCP协议保证数据传输可靠性的方式主要有：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制、丢弃重复数据。

流量控制是针对接收端接收能力的控制机制，

拥塞控制是针对当前网络的控制机制。

1. 校验和

   计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。 发送方：在发送数据之前计算检验和，并进行校验和的填充。 接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。

2. 序列号和确认应答

   序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。
   确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

3. 超时重传

   在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？

   首先，发送方没有接收到响应的ACK报文原因可能有两点：

   （1）数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。

   （2）接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。

   TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。如果是刚才第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。

4. 连接管理

   连接管理就是三次握手与四次挥手的过程，保证可靠的连接，是保证可靠性的前提。

5. 流量控制

接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。

在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

6. 拥塞控制

   TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。

   所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。

   拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。

拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。

7. 丢弃重复数据

   通过前面的知识我们知道，在确认应答时，由于确认应答消息的丢失，那么接收方可能会收到发送方的重复数据，如下图所示：
   

而此时对于业务方来说，只需要一个数据就可以了，所以 TCP 还有一个机制，丢弃重复数据的机制，这样就能保证业务方接收到的数据是正确的了。TCP 会给每一个发送的包上加上一个编号，如果接收到了编号相同的数据包，那么就说明接收端得到了重复的包，丢弃即可。

————内容源于网络