Java必知必会-TCP

目录

• 基本认识
  • • • 序列号：
      • 确认应答号：
      • 控制位：（图中黄色部分）
    • 分层模型
    • TCP特性
  • TCP粘包和拆包
    • 粘包/拆包原因
    • 如何解决拆包粘包
  • TCP连接
    • • TCP 四元组可以唯一的确定一个连接，TCP四元组包括如下：
      • 有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？
  • UDP
    • TCP 和 UDP 应用场景：
• TCP三次握手
  • • • • 一握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认。通俗来讲，客户端要和服务建立连接前，会向服务器报告说我要和你建立连接，顺便把自己的一个发送能力告知并且发给服务器。
        • 二握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态。通俗来讲，服务器判断自己是否可以和客户端创建连接，就把服务器自身的接收能力返回给客户端让客户端知道。
        • 三握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。通俗来讲，客户端收到服务器的响应后，客户端再发送一个信号表示客户端已经接收无误，双方分别的发送和接收的能力OK了，就表示可以建立连接了
• TCP四次握手
  • • DNS解析
    • TCP连接
      • HTTPS协议
      • HTTPS过程
    • HTTP请求
    • 服务器处理请求并返回HTTP报文
• TCP滑动窗口
  • • 概念
    • 窗口
    • 滑动窗口机制
      • 解决的问题
    • 工作过程
      • 滑动窗口机制总结
• 面试
  • • 从输入一个url到页面出现经历了什么过程
    • 滑动窗口与拥塞窗口

基本认识

序列号：

在建立连接时由计算机生成的随机数作为其初始值，通过 SYN (同步序列编号) 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题（类似保证幂等性）。

确认应答号：

指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决不丢包的问题。

控制位：（图中黄色部分）

• ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
• RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
• SYC：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
• FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位置为 1 的 TCP 段。

分层模型

IP 层是「不可靠」的，它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性。

如果需要保障网络数据包的可靠性，那么就需要由上层（传输层）的 TCP 协议来负责。

因为 TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。

TCP特性

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

• 面向连接：一定是「一对一」才能连接，不能像 UDP 协议 可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
• 字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节已经收到，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

TCP粘包和拆包

Tcp是个“流协议”，所谓流，就是没有界限的一连串数据，没有界限。TCP底层不了解业务数据的含义，它会根据TCP缓冲区的实际情况进行包的划分，所以业务上认为，一个完整的包可能被TCP拆分为多个包进行发送，也可能把多个小包封装成一个大的数据包进行发送，这就是所谓的TCP粘包和拆包问题。

假设客户端分别发送了两个数据包，D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下情况：

• 服务端分别收到了D1和D2，没有粘包和拆包
• 服务端一次性收到了D1和D2，称为TCP粘包
• 服务端两次读取到了两个数据包，第一次读到了D1的完整部分和D2的部分数据，第二次读到了D2的剩余部分。 这称为TCP拆包
• 服务端两次读取到两个数据包，第一次是D1的部分，第二次是D1的剩余部分和D2的完整部分

也有可能D1和D2非常大，期间发生多次拆包。

粘包/拆包原因

tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。

• 应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
• 应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
• 进行mss（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>mss的时候将发生拆包。
• 接收方法不及时读取套接字缓冲区数据，这将发生粘包。

如何解决拆包粘包

既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：

1. 使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
2. 设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。例如每个报文固定200字节，如果不够，空位补空格
3. 设置消息边界，服务端从网络流中按消息编辑分离出消息内容。
4. 将消息分为消息头和消息体，消息头中包含消息的长度，字段等信息
5. 在包尾增加回车换行符进行分割，如FTP协议
6. 更复杂的应用层协议

TCP连接

简单来说就是，用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接。

建立一个 TCP 连接是需要客户端与服务器端达成上述三个信息的共识。

• Socket：由 IP 地址和端口号组成
• 序列号：用来解决乱序问题等
• 窗口大小：用来做流量控制

TCP 四元组可以唯一的确定一个连接，TCP四元组包括如下：

• 源地址
• 源端口
• 目的地址
• 目的端口

源地址和目的地址的字段（32位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机。

源端口和目的端口的字段（16位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程。

有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？

服务器通常固定在某个本地端口上监听，等待客户端的连接请求。

因此，客户端 IP 和 端口是可变的，其理论值计算公式: 最大TCP连接数 = 客户端IP数 X 客户端的端口数

UDP

UDP 不提供复杂的控制机制，利用 IP 提供面向「无连接」的通信服务。

• 目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。
• 包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。
• 校验和：校验和是为了提供可靠的 UDP 首部和数据而设计。

TCP 和 UDP 应用场景：

由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：

• FTP 文件传输
• HTTP / HTTPS

由于 UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：

• 包总量较少的通信，如 DNS 、SNMP 等
• 视频、音频等多媒体通信
• 广播通信

TCP三次握手

• SYN：它的全称是 Synchronize Sequence Numbers，同步序列编号。是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立 TCP 连接时，首先会发送的一个信号。客户端在接收到 SYN 消息时，就会在客户端自己的段内生成一个随机值 X。
• SYN-ACK：服务器收到 SYN 后，打开客户端连接，发送一个 SYN-ACK 作为答复。确认号设置为比接收到的序列号多一个，即 X + 1，服务器为数据包选择的序列号是另一个随机数 Y。
• ACK：Acknowledge character, 确认字符，表示发来的数据已确认接收无误。最后，客户端将 ACK 发送给服务器。序列号被设置为所接收的确认值即 Y + 1。

一握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认。通俗来讲，客户端要和服务建立连接前，会向服务器报告说我要和你建立连接，顺便把自己的一个发送能力告知并且发给服务器。

二握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态。通俗来讲，服务器判断自己是否可以和客户端创建连接，就把服务器自身的接收能力返回给客户端让客户端知道。

三握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。通俗来讲，客户端收到服务器的响应后，客户端再发送一个信号表示客户端已经接收无误，双方分别的发送和接收的能力OK了，就表示可以建立连接了

TCP四次握手

在连接终止阶段使用四次挥手，连接的每一端都会独立的终止。

• 首先，客户端应用程序决定要终止连接(这里服务端也可以选择断开连接)。这会使客户端将 FIN 发送到服务器，并进入 FIN_WAIT_1 状态。当客户端处于 FIN_WAIT_1 状态时，它会等待来自服务器的 ACK 响应。
• 然后第二步，当服务器收到 FIN 消息时，服务器会立刻向客户端发送 ACK 确认消息。
• 当客户端收到服务器发送的 ACK 响应后，客户端就进入 FIN_WAIT_2 状态，然后等待来自服务器的 FIN 消息
• 服务器发送 ACK 确认消息后，一段时间（可以进行关闭后）会发送 FIN 消息给客户端，告知客户端可以进行关闭。
• 当客户端收到从服务端发送的 FIN 消息时，客户端就会由 FIN_WAIT_2 状态变为 TIME_WAIT 状态。处于 TIME_WAIT 状态的客户端允许重新发送 ACK 到服务器为了防止信息丢失。客户端在 TIME_WAIT 状态下花费的时间取决于它的实现，在等待一段时间后，连接关闭，客户端上所有的资源（包括端口号和缓冲区数据）都被释放。

DNS解析

DNS解析的过程就是寻找哪台机器上有你需要资源的过程。当你在浏览器中输入一个地址时，例如www.baidu.com，其实不是百度网站真正意义上的地址。互联网上每一台计算机的唯一标识是它的IP地址，但是IP地址并不方便记忆。用户更喜欢用方便记忆的网址去寻找互联网上的其它计算机，也就是上面提到的百度的网址。所以互联网设计者需要在用户的方便性与可用性方面做一个权衡，这个权衡就是一个网址到IP地址的转换，这个过程就是DNS解析。它实际上充当了一个翻译的角色，实现了网址到IP地址的转换。DNS解析是一个递归查询的过程。

TCP连接

HTTP协议是使用TCP作为其传输层协议的，当TCP出现瓶颈时，HTTP也会受到影响。但由于TCP优化这一块我平常接触的并不是很多，再加上大学时的计算机网络的基础基本上忘完，所以这一部分我也就不在这里分析了。

HTTPS协议

我不知道把HTTPS放在这个部分是否合适，但是放在这里好像又说的过去。HTTP报文是包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险，HTTP报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。

HTTPS过程

HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL使用了非对称加密，对称加密以及hash等。具体过程请参考经典的阮一峰先生的博客TLS/SSL握手过程。
HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。

HTTP请求

其实这部分又可以称为前端工程师眼中的HTTP，它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。

服务器处理请求并返回HTTP报文

自然而然这部分对应的就是后端工程师眼中的HTTP。后端从在固定的端口接收到TCP报文开始，这一部分对应于编程语言中的socket。它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。这一部分工作一般是由Web服务器去进行，我使用过的Web服务器有Tomcat, Jetty和Netty等等。

HTTP响应报文也是由三部分组成: 状态码, 响应报头和响应报文。

TCP滑动窗口

概念

滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。

滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。

滑动窗口解决的是流量控制的的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。接收端的缓存传输数据给应用层，但这个过程不一定是即时的，如果发送速度太快，会出现接收端数据overflow，流量控制解决的是这个问题。

“窗口”相当于允许发送和接收的数据包大小，“滑动”指窗口向数据序列的一端滑动，从而可以发送或接收新的数据序列包

窗口

窗口大小代表了设备一次能从对端处理多少数据，之后再传给应用层。缓存传给应用层的数据不能是乱序的，窗口机制保证了这一点。现实中，应用层可能无法立刻从缓存中读取数据。

发送窗口：（1）已发送，未收到ACK（2）未发送，但允许发送

接收窗口：未接收但准备接收

滑动窗口机制

1. 发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
2. 接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
3. 遵循快速重传、累计确认、选择确认等规则。
4. 发送方发的window size = 8192;就是接收端最多发送8192字节，这个8192一般就是发送方接收缓存的大小。

TCP协议里窗口机制有2种：一种是固定的窗口大小；一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。

​ TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。 假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送序列号为1、2、3的三个数据包，接收方设备成功接收数据包，用序列号4确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。

解决的问题

假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。

工作过程

首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2 。

第二次经过了第一次的发送接收过程，发送方已经知道接收方的接收数据能力和请求接收的数据序列起点，因此第二次发送方发送2个数据

看到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了这个时候开始发送第5个数据。

这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变化，并不是第一次协商好了以后就永远不变了，而是根据接收方的ACK。
滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。
只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。
收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。

滑动窗口机制总结

动画解读全过程：https://blog.csdn.net/yao5hed/article/details/81046945

1. TCP连接是通过数据包和ACK实现的，我们作为第三者可以看到双方发包的过程，但接受者在收到之前不知道发送方发的是什么，同样的，发送方在收到ACK前也不知道对方是否成功接收。

2. 发送方没有收到接收方发回的ACK，就不能向右滑动。假设发送方向接收方发了ABCD就滑动，只要对方没收到A，就不能滑动，那么就会出现二者不同步的局面。

3. 滑动窗口提高了信道利用率，TCP是发送报文段为单位的，假如每发一个报文就要等ACK，那么对于大数据包，等待时间就太长了。只要发送的报文在滑动窗口里面，不用等每个ACK回来就可以向右滑动。例如，开始接收端空着AB，只有CD，此时不能滑动；之后接收到EF和H，直接向右滑动2位，不必等G到位。

4. 窗口大小不能大于序号空间大小的一半。目的是为了不让两个窗口出现交迭，比如总大小为7，窗口大小都为4，接收窗口应当滑动4，但只剩3个序号，导致两个窗口交迭。

5. 有一种情况没出现：发送方发ABCD，接收方都收到然后向右滑动，但回复的ACK包全丢了。发送方未收到任何ACK， timeout后会重发ABCD，此时的接收方按累计确认的原则，收到ABCD后只会重发D的ACK，发送方收到后向右滑动。

面试

从输入一个url到页面出现经历了什么过程

本地缓存=》DNS解析=》TCP连接=》发送HTTP请求=》服务器收取到请求并返回HTTP报文=》浏览器解析后渲染页面=》连接结束

首先，当浏览器接收到url，会查看本地缓存(浏览器缓存-系统缓存-路由器缓存)中是否有，有则直接显示

没有则进行DNS域名解析，将域名解析成IP地址，通过ip地址去访问相应的服务器，

浏览器访问服务器的时候，会先进行tcp连接，发生三次握手

握手成功，浏览器向服务器发送http请求，请求数据（TCP处理连接，HTTP处理数据请求和发送）

服务器收到请求，进行处理，返回相应的数据至浏览器

浏览器接收服务器的响应，

读取页面内容，浏览器渲染，解析html源码

生成Dom树、解析css样式、js交互

滑动窗口与拥塞窗口

滑动窗口是控制接收以及同步数据范围的，通知发送端目前接收的数据范围，用于流量控制，接收端使用。拥塞窗口是控制发送速率的，避免发的过多，发送端使用。因为tcp是全双工，所以两边都有滑动窗口。
两个窗口的维护是独立的，滑动窗口主要由接收方反馈缓存情况来维护，拥塞窗口主要由发送方的拥塞控制算法检测出的网络拥塞程度来决定的。

拥塞窗口控制sender向connection传输数据的速率，使这个速率为网络拥堵状况的函数。