TCP核心知识点

1、TCP粘包，拆包及解决方法

产生粘包和拆包问题的主要原因是，操作系统在发送TCP数据的时候，底层会有一个缓冲区（流量窗口），例如1024个字节大小。

原因：
窗口大，数据少

• 如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；

窗口小，数据多

• 如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。

TCP 是一个面向字节流的协议，它是性质是流式的，所以它并没有分段。就像水流一样，你没法知道什么时候开始，什么时候结束。

假设客户端向服务端连续发送了两个数据包，用packet1和packet2来表示，那么服务端收到的数据可以分为三种，现列举如下：

第一种情况，接收端正常收到两个数据包，即没有发生拆包和粘包的现象，此种情况不在本文的讨论范围内。

第二种情况，接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。

第三种情况，这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。

解决办法

TCP本身是面向流的，作为网络服务器，如何从这源源不断涌来的数据流中拆分出或者合并出有意义的信息呢？通常会有以下一些常用的方法：

1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，

2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充）

3、可以在数据包之间设置边界，如添加特殊符号

2、一个TCP连接可以对应几个HTTP请求？

浏览器在与服务器建立了一个TCP连接后是否会在一个HTTP请求完成后断开？什么情况下会断开？

持久连接: 既然维持TCP连接好处这么多，HTTP/1.1就把Connection头写进标准，并且默认开启持久化连接(除非请求中声明Connection: close)，那么浏览器和服务器之间是会维持一段时间的TCP连接，不会一个请求结束就断掉。

一个TCP连接可以对应几个HTTP请求？

1、浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？

关于这个 TCP 连接后是否断开的问题，请参考：nginx中http1.1 KeepAlive 失效
我们知道 Header 中 Connection 属性决定了连接是否持久，HTTP/1.0 中 Connection 默认是 close 的，即每次请求都会重新建立和断开 TCP 连接，而在 HTTP/1.1 中 Connection 默认是 keep-alive 的，即连接可以复用，不用每次都重新建立和断开 TCP 连接。如果想主动断开连接，只需要将 Connection 属性设置为 close 即可，即 Connection: close。一般情况下复用的 TCP 连接在等待设置的超时时间之后还没有被任何连接使用的话，TCP 连接就会主动断开

2、一个 TCP 连接可以对应几个 HTTP 请求？

了解了第一个问题之后，可以得知如果维持连接的话，一个 TCP 连接是可以发送多个 HTTP 请求的

3、一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？

HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，即两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。
虽然 HTTP/1.1 规范中规定了 Pipelining 来试图解决这个问题，但是这个功能在浏览器中默认是关闭的。
先来看一下 Pipelining 是什么，RFC 2616 中规定了：

A client that supports persistent connections MAY “pipeline” its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

一个支持持久连接的客户端可以在一个连接中发送多个请求（不需要等待任意请求的响应）。收到请求的服务器必须按照请求收到的顺序发送响应。
至于标准为什么这么设