一篇搞懂tcp，http，socket，socket连接池之间的关系

作为一名开发人员我们经常会听到HTTP协议、TCP/IP协议、UDP协议、Socket、Socket长连接、Socket连接池等字眼，然而它们之间的关系、区别及原理并不是所有人都能理解清楚，这篇文章就从网络协议基础开始到Socket连接池，一步一步解释他们之间的关系。

首先从网络通信的分层模型讲起：七层模型，亦称OSI(Open System Interconnection)模型。自下往上分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。所有有关通信的都离不开它，下面这张介绍了各层所对应的一些协议和硬件

通过上图，我知道IP协议对应于网络层，TCP、UDP协议对应于传输层，而HTTP协议对应于应用层，OSI并没有Socket，那什么是Socket，后面我们将结合代码具体详细介绍。

关于传输层TCP、UDP协议可能我们平时遇见的会比较多，有人说TCP是安全的，UDP是不安全的，UDP传输比TCP快，那为什么呢，我们先从TCP的连接建立的过程开始分析，然后解释UDP和TCP的区别。

TCP的三次握手和四次分手

我们知道TCP建立连接需要经过三次握手，而断开连接需要经过四次分手，那三次握手和四次分手分别做了什么和如何进行的。

第一次握手： 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手： 服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手： 客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。通信结束客户端和服务端就断开连接，需要经过四次分手确认。

第一次分手： 主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；

第二次分手： 主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；

第三次分手： 主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；

第四次分手 ：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

可以看到一次tcp请求的建立及关闭至少进行7次通信，这还不包过数据的通信，而UDP不需3次握手和4次分手。

TCP和UDP的区别

1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。　

2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。

关于传输层我们会经常听到一些问题

1．TCP服务器最大并发连接数是多少？

关于TCP服务器最大并发连接数有一种误解就是“因为端口号上限为65535,所以TCP服务器理论上的可承载的最大并发连接数也是65535”。首先需要理解一条TCP连接的组成部分： 客户端IP、客户端端口、服务端IP、服务端端口 。所以对于TCP服务端进程来说，他可以同时连接的客户端数量并不受限于可用端口号，理论上一个服务器的一个端口能建立的连接数是全球的IP数每台机器的端口数。实际并发连接数受限于linux可打开文件数，这个数是可以配置的，可以非常大，所以实际上受限于系统性能。通过#ulimit -n 查看服务的最大文件句柄数，通过ulimit -n xxx 修改 xxx是你想要能打开的数量。也可以通过修改系统参数：

2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的Socket可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

3．TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态会产生什么问题

通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态，TIME_WAIT状态维持时间是两个MSL时间长度，也就是在1-4分钟，Windows操作系统就是4分钟。进入TIME_WAIT状态的一般情况下是客户端，一个TIME_WAIT状态的连接就占用了一个本地端口。一台机器上端口号数量的上限是65536个，如果在同一台机器上进行压力测试模拟上万的客户请求，并且循环与服务端进行短连接通信，那么这台机器将产生4000个左右的TIME_WAIT Socket，后续的短连接就会产生address already in use : connect的异常，如果使用Nginx作为方向代理也需要考虑TIME_WAIT状态，发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决。

编辑文件，加入以下内容：

然后执行 /sbin/sysctl -p 让参数生效。

netipv4tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

netipv4tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

netipv4tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

netipv4tcp_fin_timeout 修改系统默认的TIMEOUT时间

相关视频推荐

10道网络八股文，每道都很经典，让你在面试中逼格满满

徒手实现网络协议栈，请准备好环境，一起来写代码

学习地址：C/C++Linux服务器开发/后台架构师零声教育-学习视频教程-腾讯课堂

需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享

关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用(传输层)TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容。如果想要使传输的数据有意义，则必须使用到应用层协议。应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常 的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道 客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

下面是一个简单的HTTP Post application/json数据内容的请求：

现在我们了解到TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket。现在我们知道，Socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，Socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等。

不同语言都有对应的建立Socket服务端和客户端的库，下面举例Nodejs如何创建服务端和客户端：

服务端：

服务监听9000端口

下面使用命令行发送http请求和telnet

注意到curl只处理了一次报文。

客户端

Socket长连接

所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接(心跳包)，一般需要自己做在线维持。 短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接。比如Http的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。

通常的短连接操作步骤是：

连接 数据传输 关闭连接；

而长连接通常就是：

连接 数据传输 保持连接(心跳) 数据传输 保持连接(心跳) …… 关闭连接；

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理 速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成Socket错误，而且频繁的Socket创建也是对资源的浪费。

什么是心跳包为什么需要：

心跳包就是在客户端和服务端间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。网络中的接收和发送数据都是使用Socket进行实现。但是如果此套接字已经断开（比如一方断网了），那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。也可以自己定义，所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”,以确保链接的有效性。

实现：

服务端：

服务端输出结果：

客户端代码：

客户端输出结果：

如果想要使传输的数据有意义，则必须使用到应用层协议比如Http、Mqtt、Dubbo等。基于TCP协议上自定义自己的应用层的协议需要解决的几个问题：

下面我们就一起来定义自己的协议，并编写服务的和客户端进行调用：

定义报文头格式： length:000000000xxxx; xxxx代表数据的长度，总长度20,举例子不严谨。

数据表的格式: Json

服务端:

日志打印：

客户端

日志打印：

客户端定时发送自定义协议数据到服务端，先发送头数据，在发送内容数据，另外一个定时器发送心跳数据，服务端判断是心跳数据，再判断是不是头数据，再是内容数据，然后解析后再发送数据给客户端。从日志的打印可以看出客户端先后writeheader和data数据，服务端可能在一个data事件里面接收到。

这里可以看到一个客户端在同一个时间内处理一个请求可以很好的工作，但是想象这么一个场景，如果同一时间内让同一个客户端去多次调用服务端请求，发送多次头数据和内容数据，服务端的data事件收到的数据就很难区别哪些数据是哪次请求的，比如两次头数据同时到达服务端，服务端就会忽略其中一次，而后面的内容数据也不一定就对应于这个头的。所以想复用长连接并能很好的高并发处理服务端请求，就需要连接池这种方式了。

什么是Socket连接池,池的概念可以联想到是一种资源的集合，所以Socket连接池，就是维护着一定数量Socket长连接的集合。它能自动检测Socket长连接的有效性，剔除无效的连接，补充连接池的长连接的数量。从代码层次上其实是人为实现这种功能的类，一般一个连接池包含下面几个属性：

场景： 一个请求过来，首先去资源池要求获取一个长连接资源，如果空闲队列里面有长连接，就获取到这个长连接Socket,并把这个Socket移到正在运行的长连接队列。如果空闲队列里面没有，且正在运行的队列长度小于配置的连接池资源的数量，就新建一个长连接到正在运行的队列去，如果正在运行的不下于配置的资源池长度，则这个请求进入到等待队列去。当一个正在运行的Socket完成了请求，就从正在运行的队列移到空闲的队列，并触发等待请求队列去获取空闲资源，如果有等待的情况。

这里简单介绍Nodejs的Socket连接池generic-pool模块的源码。

主要文件目录结构

下面介绍库的使用：

初始化连接池

使用连接池

下面连接池的使用，使用的协议是我们之前自定义的协议。

日志打印：

这里看到前面两个请求都建立了新的Socket连接 socket_pool 127001 9000 connect，定时器结束后重新发起两个请求就没有建立新的Socket连接了，直接从连接池里面获取Socket连接资源。

源码分析

发现主要的代码就位于lib文件夹中的Pooljs

构造函数：

lib/Pooljs

可以看到包含之前说的空闲的资源队列，正在请求的资源队列，正在等待的请求队列等。

下面查看 Poolacquire 方法

lib/Pooljs

上面的代码就按种情况一直走下到最终获取到长连接的资源，其他更多代码大家可以自己去深入了解。

tcpdump -XvvennSs 0 -i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0x4745 为"GET"前两个字母"GE"

0x4854 为"HTTP"前两个字母"HT"

说明： 通常情况下:一个正常的TCP连接，都会有三个阶段:1、TCP三次握手;2、数据传送;3、TCP四次挥手

里面的几个概念：

SYN: (同步序列编号,Synchronize Sequence Numbers)

ACK: (确认编号,Acknowledgement Number)

FIN: (结束标志,FINish)

TCP三次握手(创建 OPEN)

客户端发起一个和服务创建TCP链接的请求，这里是SYN(J)

服务端接受到客户端的创建请求后，返回两个信息： SYN(K) + ACK(J+1)

客户端在接受到服务端的ACK信息校验成功后(J与J+1)，返回一个信息：ACK(K+1)

服务端这时接受到客户端的ACK信息校验成功后(K与K+1)，不再返回信息，后面进入数据通讯阶段

数据通讯

客户端/服务端 read/write数据包

TCP四次握手(关闭 finish)

客户端发起关闭请求，发送一个信息：FIN(M)

服务端接受到信息后，首先返回ACK(M+1),表明自己已经收到消息。

服务端在准备好关闭之前，最后发送给客户端一个 FIN(N)消息，询问客户端是否准备好关闭了

客户端接受到服务端发送的消息后，返回一个确认信息: ACK(N+1)

最后，服务端和客户端在双方都得到确认时，各自关闭或者回收对应的TCP链接。

详细的状态说明(以及linux相关参数调整)

SYN_SEND

客户端尝试链接服务端，通过open方法。也就是TCP三次握手中的第1步之后,注意是客户端状态

sysctl -w netipv4tcp_syn_retries = 2 ,做为客户端可以设置SYN包的重试次数，默认5次(大约180s)引用校长的话：仅仅重试2次，现代网络够了

SYN_RECEIVED

服务接受创建请求的SYN后，也就是TCP三次握手中的第2步，发送ACK数据包之前

注意是服务端状态,一般15个左右正常，如果很大，怀疑遭受SYN_FLOOD攻击

sysctl -w netipv4tcp_max_syn_backlog=4096 , 设置该状态的等待队列数，默认1024，调大后可适当防止syn-flood，可参见man 7 tcp

sysctl -w netipv4tcp_syncookies=1 ,　打开syncookie，在syn backlog队列不足的时候，提供一种机制临时将syn链接换出

sysctl -w netipv4tcp_synack_retries = 2 ,做为服务端返回ACK包的重试次数，默认5次(大约180s)引用校长的话：仅仅重试2次，现代网络够了

ESTABLISHED

客户端接受到服务端的ACK包后的状态，服务端在发出ACK在一定时间后即为ESTABLISHED

sysctl -w netipv4tcp_keepalive_time = 1200 ，默认为7200秒(2小时)，系统针对空闲链接会进行心跳检查，如果超过netipv4tcp_keepalive_probes netipv4tcp_keepalive_intvl = 默认11分，终止对应的tcp链接，可适当调整心跳检查频率

目前线上的监控 waring:600 , critial : 800

FIN_WAIT1

主动关闭的一方，在发出FIN请求之后，也就是在TCP四次握手的第1步

CLOSE_WAIT

被动关闭的一方，在接受到客户端的FIN后，也就是在TCP四次握手的第2步

FIN_WAIT2

主动关闭的一方，在接受到被动关闭一方的ACK后，也就是TCP四次握手的第2步

sysctl -w netipv4tcp_fin_timeout=30, 可以设定被动关闭方返回FIN后的超时时间，有效回收链接，避免syn-flood

LASK_ACK

被动关闭的一方，在发送ACK后一段时间后(确保客户端已收到)，再发起一个FIN请求。也就是TCP四次握手的第3步

TIME_WAIT

主动关闭的一方，在收到被动关闭的FIN包后，发送ACK。也就是TCP四次握手的第4步

sysctl -w netipv4tcp_tw_recycle = 1 , 打开快速回收TIME_WAIT，Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation)

sysctl -w netipv4tcp_tw_reuse =1, 快速回收并重用TIME_WAIT的链接, 貌似和tw_recycle有冲突，不能重用就回收

netipv4tcp_max_tw_buckets: 处于time_wait状态的最多链接数，默认为180000

相关说明

主动关闭方在接收到被动关闭方的FIN请求后，发送成功给对方一个ACK后,将自己的状态由FIN_WAIT2修改为TIME_WAIT，而必须 再等2倍的MSL(Maximum Segment Lifetime,MSL是一个数据报在internetwork中能存在的时间)时间之后双方才能把状态 都改为CLOSED以关闭连接。目前RHEL里保持TIME_WAIT状态的时间为60秒

keepAlive策略可以有效的避免进行三次握手和四次关闭的动作

其他网络重要参数

netipv4tcp_rmem 参数

默认值： min=4096 default=87380 max=4194304

netipv4tcp_wmem 参数

默认值： min=4096 default=16384 max=4194304

tcpdump

tcpdump是linux系统自带的抓包工具，主要通过命令行的方式，比较适合在线上服务器进行抓包操作，如果是windows或者ubuntu完全可 以选择一些图形化的工具，ubuntu比较推荐用wireshark，安装方式很简单sudo apt一下即可。

命令行格式：

tcpdump [ -adeflnNOpqStvx ] [ -c 数量 ] [ -F 文件名 ][ -i 网络接口 ] [ -r 文件名] [ -s snaplen ][ -T 类型 ] [ -w 文件名 ] [表达式 ]

常用的参数：

-l　　使标准输出变为缓冲行形式；

-n　 不把网络地址转换成名字；

-c　　在收到指定的包的数目后，tcpdump就会停止；

-i　　指定监听的网络接口；(如果没有指定可能在默认网卡上监听，需要指定绑定了特定IP的网卡)

-w　 直接将包写入文件中，并不分析和打印出来；

-s 指定记录package的大小，常见 -s 0 ，代表最大值65535，一半linux传输最小单元MTU为1500，足够了

-X 直接输出package data数据，默认不设置，只能通过-w指定文件进行输出

常用表达式：

关于类型的关键字，主要包括host，net，port

传输方向的关键字，主要包括src , dst ,dst or src, dst and src

协议的关键字，主要包括fddi,ip ,arp,rarp,tcp,udp等类型

逻辑运算，取非运算是 'not ' '! ', 与运算是'and','&&';或运算 是'or' ,'||'

其他重要的关键字如下：gateway, broadcast,less,greater

实际例子：

1 http数据包抓取 (直接在终端输出package data)

tcpdump tcp port 80 -n -X -s 0 指定80端口进行输出

2 抓取http包数据指定文件进行输出package

tcpdump tcp port 80 -n -s 0 -w /tmp/tcpcap

对应的/tmp/tcpcap基本靠肉眼已经能看一下信息，比如http Header , content信息等

3 结合管道流

tcpdump tcp port 80 -n -s 0 -X -l | grep xxxx

这样可以实时对数据包进行字符串匹配过滤

4 mod_proxy反向代理抓包

线上服务器apache+jetty，通过apache mod_proxy进行一个反向代理，80 apache端口, 7001 jetty端口

apache端口数据抓包：　tcpdump tcp port 80 -n -s 0 -X -i eth0　注意：指定eth0网络接口

jetty端口数据抓包：　tcpdump tcp port 7001 -n -s 0 -X -i lo 注意：指定Loopback网络接口

5 只监控特定的ip主机

tcpdump tcp host 1016285 and port 2100 -s 0 -X　

需要使用tcp表达式的组合，这里是host指示只监听该ip

小技巧：

1 可结合tcpdump(命令) + wireshark(图形化)

操作：　

在服务器上进行tcpdump -w /tmp/tcpcap 指定输出外部文件

scp /tmp/tcpcap 拷贝文件到你本地

wireshark &启动wireshark

通过　File -> Open打开拷贝下来的文件，这样就可以利用进行数据包分析了

剩下来的事就非常方便了

阿里云服务器偶尔连接不上的问题出现在我做了一些TCP优化之后，出现了公司内网偶尔会出现连接不上服务器的问题，但是切换其他的网络就可以正常连接。

1，登陆服务器查看资源使用top，vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层。

2，本地使用ping服务器外网ip正常返回，无丢包，延迟也正常。

3，登录服务器查看tcp相关数据。

发现在卡顿时有大量tcp syn包被丢弃，数值一直在增长。

在查阅资料并结合实际情况后，发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。

后想起，之前同事为改善time_wait连接数过多问题曾改过该内核参数。

解决办法是，关闭tcp_tw_recycle：

再观察，发现服务已正常，偶尔连接不上的现象消失。

我们先来man一下这两个参数(man tcp)：

cp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）

关于tcp_timestamps详情请见： https://toolsietforg/pdf/rfc7323pdf

开启tcp_tw_recycle会启用tcp time_wait的快速回收，这个参数不建议在NAT环境中启用，它会引起相关问题。

tcp_tw_recycle是依赖tcp_timestamps参数的，在一般网络环境中，可能不会有问题，但是在NAT环境中，问题就来了。比如我遇到的这个情况，办公室的外网地址只有一个，所有人访问后台都会通过路由器做SNAT将内网地址映射为公网IP，由于服务端和客户端都启用了tcp_timestamps，因此TCP头部中增加时间戳信息，而在服务器看来，同一客户端的时间戳必然是线性增长的，但是，由于我的客户端网络环境是NAT，因此每台主机的时间戳都是有差异的，在启用tcp_tw_recycle后，一旦有客户端断开连接，服务器可能就会丢弃那些时间戳较小的客户端的SYN包，这也就导致了网站访问极不稳定。

主机A SIP:P1 (时间戳T0) ---> Server 主机A断开后

主机B SIP:P1 (时间戳T2) T2 < T0 ---> Server 丢弃

经过此次故障，告诫我们在处理线上问题时，不能盲目修改参数，一定要经过测试，确认无误后，再应用于生产环境。同时，也要加深对相关内核参数的认识和理解。

本文解决灵感来自于 https://blog51ctocom/hld1992/2285410

https://blogcsdnnet/chengm8/article/details/51668992

第一步：安装IIS

A选择“添加/删除程序”控制面板中，选择显示在对话框中的“添加/删除Windows组件”。

B在出现选择安装Internet信息服务（IIS）复选框，此组件是关于空间19MB。

C单击“下一步”和Win2000安装光盘插入CD-ROM驱动器，安装程序将程序文件复制到硬盘驱动器，点击“Finish”完成。

第二步：

A打开IIS服务器的配置窗口中选择“启动：在IIS Web服务器的基本配置

IIS Web服务器包括以下几个部分基本配置“→”程序“→”管理工具“→”Internet服务管理器“或”选择“→”控制面板“→”管理工具“→”Internet服务管理器“也可，打开的窗口。

B在打开右键单击“默认Web站点”，选择“属性”菜单中的窗口。

C在“默认Web站点属性”窗口中，选择“主目录”选项卡，在硬盘上建立一个Web内容的位置，默认目录为“C：\ inetpub \ wwwroot的”，你可能需要建立自己的。

D选择“文档”选项卡中的属性窗口中，设置自己的默认主页的名称，如“Myfirstwebhtm”，添加和移动到列表的顶部。正在

E确认默认的Web站点已经启动，如果没有可以在“默认Web站点”上单击右键，选择“开始”，在打开的IE浏览器的地址输入本机的IP地址酒吧，你可以看到他们指定的家庭已经开始在互联网上发布。 IIS

这里只介绍最基本的设置选项，你也可以去特定的设置按照上面提到的“默认Web站点属性”的需要，通过它来配置IIS的安全和其他一些参数。

IIS中，虽然使用方便，但案件是默认安装的，它也有很多安全漏洞，包括Unicode的CGI漏洞和漏洞的名字，所以在IIS安装完成，它是建议继续下载微软的主页上，他们提供安装安全补丁SP1和SP2。此外，建议在磁盘的文件系统转换为NTFS格式，分区安装系统可以安装在系统中等待的转换，也可以在以后的转化PQMagic的其它工具安装系统。

TCP协议是在TCP/IP协议模型中的运输层中很重要的一个协议、负责处理主机端口层面之间的数据传输。主要有以下特点：

1TCP是面向链接的协议，在数据传输之前需要通过三次握手建立TCP链接，当数据传递完成之后，需要通过四次挥手进行连接释放。

2每一条TCP通信都是两台主机和主机之间的，是点对点传输的协议。

3TCP提供可靠的、无差错、不丢失、不重复，按序到达的服务。

4TCP的通信双方在连接建立的任何时候都可以发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。

5面向字节流。在数据传输的过程中如果报文比较长的话TCP会进行数据分段传输，每一条分段的TCP传输信息都带有分段的序号，每一段都包含一部分字节流。接收方根据每段携带的的序号信息进行数据拼接，最终拼接出来初始的传输数据。但是在整个传输的过程中每一段TCP携带的都是被切割的字节流数据。所以说TCP是面向字节流的。

aTCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用程序给出的）。

b如果应用程序传送到TCP缓存的数据块太大，TCP就可以把它划分短一些再传。TCP也可以等待积累有足够多的字节后再构建成报文段发送出去。

各字段含义：

源端口：发送端的端口号

目的端口：接收端的端口号

序号：TCP将发送报文分段传输的时候会给每一段加上序号，接收端也可以根据这个序号来判断数据拼接的顺序，主要用来解决网络报乱序的问题

确认号：确认号为接收端收到数据之后进行排序确认以及发送下一次期待接收到的序号，数值 = 接收到的发送号 + 1

数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移以32位为长度单位，因此TCP首部的最大长度是60（154）个字节。

控制位：

URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促 中间层设备要尽快处理这些数据;

ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值：0和1， 为1的时候表示应答域有效，反之为0;

PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序， 而不是在缓冲区中排队;

RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包;

SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1， ACK=0;连接被响应的时候，SYN=1，ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送 一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口;但是由于这 种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全 的主机将会强制要求一个连接严格的进行TCP的三次握手;

FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志 位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

窗口：TCP里很重要的一个机制，占2字节，表示报文段发送方期望接收的字节数，可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。后面会有实例讲解。

校验和：校验和包含了伪首部、TCP首部和数据，校验和是TCP强制要求的，由发送方计算，接收方验证

紧急指针：URG标志为1时，紧急指针有效，表示数据需要优先处理。紧急指针指出在TCP段中的紧急数据的最后一个字节的序号，使接收方可以知道紧急数据共有多长。

选项：最常用的选项是最大段大小（Maximum Segment Size，MSS），向对方通知本机可以接收的最大TCP段长度。MSS选项只在建立连接的请求中发送。

放在以太网帧里看TCP的位置

TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。

因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。

以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右

一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。

发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。

第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。

收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。

对于应用程序来说，不用关心数据通信的细节。除非线路异常，否则收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。

TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。

操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。

应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。

服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。

最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。

TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。

Linux 内核里面 设定 了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。

默认情况下，接收方每收到 两个 TCP 数据包，就要 发送 一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。

ACK 携带两个信息。

发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。

注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。

即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。

TCP 协议可以保证数据通信的完整性，这是怎么做到的？

前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。

举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。

如果发送方发现收到 三个 连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。

TCP是一个滑动窗口协议，即一个TCP连接的发送端在某个时刻能发多少数据是由滑动窗口控制的，而滑动窗口的大小实际上是由两个窗口共同决定的，一个是接收端的通告窗口，这个窗口值在TCP协议头部信息中有，会随着数据的ACK包发送给发送端，这个值表示的是在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，通告窗口大小与接收端的进程取出数据的快慢有关。另一个窗口是发送端的拥塞窗口(Congestion window)，由发送端维护这个值，在协议头部信息中没有，滑动窗口的大小就是通告窗口和拥塞窗口的较小值，所以拥塞窗口也看做是发送端用来进行流量控制的窗口。滑动窗口的左边沿向右移动称为窗口合拢，发生在发送的数据被确认时（此时，表明数据已被接收端收到，不会再被需要重传，可以从发送端的发送缓存中清除了），滑动窗口的右边沿向右移动称为窗口张开，发生在接收进程从接收端协议缓存中取出数据时。随着发送端不断收到的被发送数据的ACK包，根据ACK包中的确认序号和通告窗口大小使滑动窗口得以不断的合拢和张开，形成滑动窗口的向前滑动。如果接收进程一直不取数据，则会出现0窗口现象，即滑动窗口左边沿与右边沿重合，此时窗口大小为0，就无法再发送数据。

在TCP里，接收端(B)会给发送端(A)报一个窗口的大小，叫Advertised window。

1在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在

未收到确认之前都必须暂时保留，以便在超时重传时使用。

2发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续

发送更多数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。

3发送窗口后沿的后面部分表示已发送且已收到确认。这些数据显然不需要再保留了。

4发送窗口前沿的前面部分表示不允许发送的，应为接收方都没有为这部分数据保留临时存放的缓存空间。

5发送窗口后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）

6发送窗口前沿的变化情况有两种：不断向前移或可能不动（没收到新的确认）

TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。这种重传的概念很简单，但重传时间的选择确是TCP最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到响应的确认的时间

这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间。超时重传时间RTO略大于加权平均往返时间

RTT：

即Round Trip Time，表示从发送端到接收端的一去一回需要的时间，tcp在数据传输过程中会对RTT进行采样（即对发送的数据包及其ACK的时间差进行测量，并根据测量值更新RTT值，具体的算法TCPIP详解里面有），TCP根据得到的RTT值更新RTO值，即Retransmission TimeOut，就是重传间隔，发送端对每个发出的数据包进行计时，如果在RTO时间内没有收到所发出的数据包的对应ACK，则任务数据包丢失，将重传数据。一般RTO值都比采样得到的RTT值要大。

如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

答案是可以的，选择确认就是一种可行的处理方法。

如果要使用选项确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，

那么原来首部中的“确认号字段”的用法仍然不变。SACK文档并没有明确发送方应当怎么响应SACK因此大多数的实现还是重传所有未被确认的数据块。

一般说来，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

在计算机网络中的链路容量，交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。

拥塞控制方法：

1慢开始和拥塞避免

2快重传和快恢复

3随机早期检测

1一开始，客户端和服务端都处于CLOSED状态

2先是服务端主动监听某个端口，处于LISTEN状态（比如服务端启动，开始监听）。

3客户端主动发起连接SYN，之后处于SYN-SENT状态（第一次握手，发送 SYN = 1 ACK = 0 seq = x ack = 0）。

4服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态（第二次握手，发送 SYN = 1 ACK = 1 seq = y ack = x + 1）。

5客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态（第三次握手，发送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。

6服务端收到客户端的ACK之后，处于ESTABLISHED状态。

（需要注意的是，有可能X和Y是相等的，可能都是0，因为他们代表了各自发送报文段的序号。）

TCP连接释放四次挥手

1当前A和B都处于ESTAB-LISHED状态。

2A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。

3B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP连接处于半关闭状态，即A已经没有数据发送了。

从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。

4A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文端。

5若B已经没有向A发送的数据，B发出连接释放信号，这时B进入LAST-ACK(最后确认)状态等待A的确认。

6A再收到B的连接释放消息后，必须对此发出确认，然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME－WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。

7。B收到A发出的确认消息后，进入CLOSED状态。

以请求百度为例，看一下三次握手真实数据的TCP连接建立过程

我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释，若有错误之处请指出。

第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。

第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。

第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。

第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

原因有二：

一、保证TCP协议的全双工连接能够可靠关闭

二、保证这次连接的重复数据段从网络中消失

先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

硬件速度

网络和服务器的负载

请求和响应报文的尺寸

客户端和服务器之间的距离

TCP 协议的技术复杂性

TCP 连接建立握手；

TCP 慢启动拥塞控制；

数据聚集的 Nagle 算法；

用于捎带确认的 TCP 延迟确认算法；

TIME_WAIT 时延和端口耗尽。

介绍完毕，就这？

是的，就这。

补充：

大部分内容为网络整理，方便自己学习回顾，参考文章：

TCP 协议简介

TCP协议图文详解

什么是TCP协议？

wireshark抓包分析——TCP/IP协议

TCP协议的三次握手和四次挥手

TCP协议详解

TCP带宽和时延的研究(1)

题主是否想询问“tcpserver保存接收的文件在哪”？msedgedll。tcpserver指的是一个多线程的Tcp服务器，该服务器使用ServerSocketPoco的一个用于初始化服务器的socket的类，来接收链接。其接收的文件在电脑c硬盘中的msedgedll文件，用以保存，tcpserver的主要作用是为到来的链接维护一个队列。

为什么要有三次握手，因为如果只有两次握手，那么

第一次：客户端发送一个syn包给服务器，里面有一个随机生成的syn，然后客户端处于syn_send状态

第二次：服务端收到客户端发来的syn包之后，确认syn包，也就是生成一个ack=syn+1，然后再自己随机生成一个syn包，即syn+ack包，然后返回给客户端，自己变成syn_recv状态

第三次：客户端收到服务端发来的syn+ack包之后，确认ack是正确的之后，返回一个ack=syn+1给服务端，此包发送完毕，客户端进入了ESTABLISHED状态，服务端收到ack包后也进入ESTABLISHED状态。

SYN攻击，当第二次握手服务端发送了syn+ack包之后，收到客户端发送的ack之前这段时间的tcp链接成为半连接，此时服务端处于syn_recv状态。当大量客户端随机IP疯狂发送tcp链接请求时，客户端以为是不同用户的请求，所以队列中全是半连接，然后导致服务器宕机，正常请求被丢弃。

第一个包发送过程丢失

A会周期性超时重传，直到收到B的确认

第二个包发送过程丢失

B会周期性超时重传，直到收到A的确认

第三个包发送过程丢失

A发送完数据后单方面进入TCP的ESTABLISHED状态，B还处于半链接：

TCP协议为什么需要三次握手？

第一次：客户端发送一个fin给服务端表示自己要断开连接了，然后进入fin_wait_1状态

第二次：服务端收到fin后，发送一个ack=fin+1给客户端，服务端进入close_wait状态，客户端进入fin_wait_2状态

第三次：服务端发送一个fin，用来关闭服务端到客户端的数据传输，服务端进入last_ack状态

第四次：客户端收到fin后，进入time_wait状态，然后发送一个ack=fin+1给服务端，服务端确认后进入close状态，完成四次挥手

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

答案解析：

浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。

在 HTTP/10 中，一个http请求收到服务器响应后，会断开对应的TCP连接。这样每次请求，都需要重新建立TCP连接，这样一直重复建立和断开的过程，比较耗时。所以为了充分利用TCP连接，可以设置头字段 Connection: keep-alive ，这样http请求完成后，就不会断开当前的TCP连接，后续的http请求可以使用当前TCP连接进行通信。

第一次访问有初始化连接和SSL开销

初始化连接和SSL开销消失了，说明使用的是同一个TCP连接。

HTTP/11 将 Connection 写入了标准，默认值为 keep-alive 。除非强制设置为 Connection: close ，才会在请求后断开TCP连接。

所以这一题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求头中设置 Connection: close 才会在请求后关闭TCP连接。

HTTP/11 中，单个TCP连接，在同一时间只能处理一个http请求，虽然存在Pipelining技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。

HTTP2 提供了多路传输功能，多个http请求，可以同时在同一个TCP连接中进行传输。

页面资源请求时，浏览器会同时和服务器建立多个TCP连接，在同一个TCP连接上顺序处理多个HTTP请求。所以浏览器的并发性就体现在可以建立多个TCP连接，来支持多个http同时请求。

Chrome浏览器最多允许对同一个域名Host建立6个TCP连接，不同的浏览器有所区别。

补充

如果都是HTTPS的连接，并且在同一域名下，浏览器会先和服务器协商使用 HTTP2 的 Multiplexing 功能进行多路传输，不过未必所有的挂在这个域名下的资源都会使用同一个TCP连接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上实现的），那么浏览器会就在同一个host建立多个TCP连接，每一个TCP连接进行顺序请求资源。

参考：

[1] 第8题-浏览器HTTP请求并发数和TCP连接的关系