当前位置：文档之家 › TCP三次握手详解

TCP三次握手详解

  • 格式：pdf
  • 大小：176.77 KB
  • 文档页数：4

TCP三次握⼿详解

问题描述

场景：JAVA的client和server，使⽤socket通信。server使⽤NIO。

1.间歇性得出现client向server建⽴连接三次握⼿已经完成，但server的selector没有响应到这连接。

2.出问题的时间点，会同时有很多连接出现这个问题。

3.selector没有销毁重建，⼀直⽤的都是⼀个。

4.程序刚启动的时候必会出现⼀些，之后会间歇性出现。

分析问题

正常TCP建连接三次握⼿过程：

第⼀步：client 发送 syn 到server 发起握⼿；

第⼆步：server 收到 syn后回复syn+ack给client；

第三步：client 收到syn+ack后，回复server⼀个ack表⽰收到了server的syn+ack（此时client的56911端⼝的连接已经是established）

从问题的描述来看，有点像TCP建连接的时候全连接队列（accept队列，后⾯具体讲）满了，尤其是症状2、4. 为了证明是这个原因，马上

通过 netstat -s | egrep "listen" 去看队列的溢出统计数据：

667399 times the listen queue of socket overflowed

反复看了⼏次之后发现这个overflowed ⼀直在增加，那么可以明确的是server上全连接队列⼀定溢出了。

接着查看溢出后，OS怎么处理：

cat /proc/sys/net/ipv4/tcp_abort_on_overflow

0

tcp_abort_on_overflow 为0表⽰如果三次握⼿第三步的时候全连接队列满了那么server扔掉client 发过来的ack（在server端认为连接还没建

⽴起来）

为了证明客户端应⽤代码的异常跟全连接队列满有关系，我先把tcp_abort_on_overflow修改成 1，1表⽰第三步的时候如果全连接队列满

了，server发送⼀个reset包给client，表⽰废掉这个握⼿过程和这个连接（本来在server端这个连接就还没建⽴起来）。

接着测试，这时在客户端异常中可以看到很多connection reset by peer的错误，到此证明客户端错误是这个原因导致的（逻辑严谨、快速证

明问题的关键点所在）。

于是开发同学翻看java 源代码发现socket 默认的backlog（这个值控制全连接队列的⼤⼩，后⾯再详述）是50，于是改⼤重新跑，经过12个

⼩时以上的压测，这个错误⼀次都没出现了，同时观察到 overflowed 也不再增加了。

到此问题解决，简单来说TCP三次握⼿后有个accept队列，进到这个队列才能从Listen变成accept，默认backlog 值是50，很容易就满了。

满了之后握⼿第三步的时候server就忽略了client发过来的ack包（隔⼀段时间server重发握⼿第⼆步的syn+ack包给client），如果这个连接

⼀直排不上队就异常了。

但是不能只是满⾜问题的解决，⽽是要去复盘解决过程，中间涉及到了哪些知识点是我所缺失或者理解不到位的；这个问题除了

上⾯的异常信息表现出来之外，还有没有更明确地指征来查看和确认这个问题。

深⼊理解TCP握⼿过程中建连接的流程和队列

如上图所⽰，这⾥有两个队列：syns queue(半连接队列）；accept queue（全连接队列）。

三次握⼿中，在第⼀步server收到client的syn后，把这个连接信息放到半连接队列中，同时回复syn+ack给client（第⼆步）；

题外话，⽐如syn floods 攻击就是针对半连接队列的，攻击⽅不停地建连接，但是建连接地时候只做第⼀步，第⼆步中攻击⽅收到server地

syn+ack后故意扔掉什么都不做，导致server上这个队列满其他正常请求⽆法进来

第三步的时候server收到client的ack，如果这时全连接队列没满，那么从半连接队列拿出这个连接的信息放⼊到全连接队列中，否则按

tcp_abort_on_overflow指⽰的执⾏。

这时如果全连接队列满了并且tcp_abort_on_overflow是0的话，server过⼀段时间再次发送syn+ack给client（也就是重新⾛握⼿的第⼆

步），如果client超时等待⽐较短，client就很容易异常了。

在我们的os中retry 第⼆步的默认次数是2（centos默认是5次）：

net.ipv4.tcp_synack_retries=2

如果TCP连接队列溢出，有哪些指标可以看呢？

上述解决过程有点绕，听起来懵，那么下次再出现类似问题有什么更快更明确的⼿段来确认这个问题呢？（通过具体的、感性的东西来强化

我们对知识点的理解和吸收。）

netstat -s|egrep "listen|LISTEN"

667399 times the listen queue of a socket overflowed

⽐如上⾯看到的 667399 times ，表⽰全连接队列溢出的次数，隔⼏秒钟执⾏下，如果这个数字⼀直在增加的话肯定全连接队列偶尔满了。

ss 命令

ss -lnt

Recv-Q Send-Q Local Address:Port Peer Address:Port

0 50 *:3306 *:*

上⾯看到的第⼆列Send-Q 值是50，表⽰第三列的listen端⼝上的全连接队列最⼤为50，第⼀列Recv-Q为全连接队列当前使⽤了多少。

全连接队列的⼤⼩取决于：min(backlog, somaxconn) . backlog是在socket创建的时候传⼊的，somaxconn是⼀个os级别的系统参数。

这个时候可以跟我们的代码建⽴联系了，⽐如Java创建ServerSocket的时候会让你传⼊backlog的值：

ServerSocket()

Creates an unbound server socket.

ServerSocket(int port)

Creates a server socket, bound to the specified port.

ServerSocket(int port, int backlog)

Creates a server socket and binds it to the specified local port number, with the specified backlog.

ServerSocket(int port, int backlog, InetAddress bindAddr)

Create a server with the specified port, listen backlog, and local IP address to bind to.

半连接队列的⼤⼩取决于：max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)，不同版本的os会有些差异。 我们写代码的时候从来没有想过这个backlog或者说⼤多时候就没给他值（那么默认就是50），直接忽视了他，⾸先这是⼀个知

识点的盲点；其次也许哪天你在哪篇⽂章中看到了这个参数，当时有点印象，但是过⼀阵⼦就忘了，这是知识之间没有建⽴连

接，不是体系化的。但是如果你跟我⼀样⾸先经历了这个问题的痛苦，然后在压⼒和痛苦的驱动⾃⼰去找为什么，同时能够把为

什么从代码层推理理解到OS层，那么这个知识点你才算是⽐较好地掌握了，也会成为你的知识体系在TCP或者性能⽅⾯成长⾃

我⽣长的⼀个有⼒抓⼿。

netstat 命令

netstat跟ss命令⼀样也能看到Send-Q、Recv-Q这些状态信息，不过如果这个连接不是Listen状态的话，Recv-Q就是指收到的数据还在缓存

中，还没被进程读取，这个值就是还没被进程读取的 bytes；⽽ Send 则是发送队列中没有被远程主机确认的 bytes 数。

netstat -tn

Active Internet connections(w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp0 0 server:8182 client-1:15260 SYN_RECV

tcp0 28 server:22 client-1:51708 ESTABLISHED

netstat -tn 看到的 Recv-Q 跟全连接半连接没有关系，这⾥特意拿出来说⼀下是因为容易跟 ss -lnt 的 Recv-Q 搞混淆，顺便建⽴知识体系，

巩固相关知识点 。

⽐如如下netstat -t 看到的Recv-Q有⼤量数据堆积，那么⼀般是CPU处理不过来导致的

上⾯是通过⼀些具体的⼯具、指标来认识全连接队列（⼯程效率的⼿段）。

实践验证⼀下上⾯的理解

把java中backlog改成10（越⼩越容易溢出），继续跑压⼒，这个时候client⼜开始报异常了，然后在server上通过 ss 命令观察到：

ss -lnt

Recv-Q Send-Q Local Address:Port Peer Address:Port

11 10 *:3306 *:*

按照前⾯的理解，这个时候我们能看到3306这个端⼝上的服务全连接队列最⼤是10，但是现在有11个在队列中和等待进队列的，肯定有⼀

个连接进不去队列要overflow掉，同时也确实能看到overflow的值在不断地增⼤。

Tomcat和Nginx中的Accept队列参数

Tomcat默认短连接，backlog（Tomcat⾥⾯的术语是Accept count）Ali-tomcat默认是200, Apache Tomcat默认100。

ss -lnt

Recv-Q Send-Q Local Address:Port Peer Address:Port

0 100 *:8080 *:*

Nginx默认是511

ss -lnt

State Recv-Q Send-Q Local Address:Port Peer Address:Port

LISTEN 0 511 *:8085 *:*

LISTEN 0 511 *:8085 *:*

因为Nginx是多进程模式，所以看到了多个8085，也就是多个进程都监听同⼀个端⼝以尽量避免上下⽂切换来提升性能

总结

全连接队列、半连接队列溢出这种问题很容易被忽视，但是⼜很关键，特别是对于⼀些短连接应⽤（⽐如Nginx、PHP，当然他们也是⽀持

长连接的）更容易爆发。 ⼀旦溢出，从cpu、线程状态看起来都⽐较正常，但是压⼒上不去，在client看来rt也⽐较⾼（rt=⽹络+排队+真正服

务时间），但是从server⽇志记录的真正服务时间来看rt⼜很短。

合集下载

简述tcp使用三次握手建立连接的过程。

简述tcp使用三次握手建立连接的过程。

简述tcp使用三次握手建立连接的过程。

TCP使用三次握手建立连接是为了确保通信双方能够建立可靠的连接，保证数据能够准确可靠地传输。

第一次握手：客户端向服务器发送一个SYN包，其中包含客户端的初始序列号（ISN）。客户端进入SYN_SENT状态，等待服务器的确认。

第二次握手：服务器收到客户端的SYN包后，发送一个SYN-ACK包作为回应。这个包中包含服务器的初始序列号（ISN），同时也确认了客户端的SYN包。服务器进入SYN-RCVD状态。

第三次握手：客户端收到服务器的SYN-ACK包后，发送一个ACK包作为回应。这个ACK包会确认服务器的SYN-ACK包，并包含客户端确认序列号（ACK）。服务器收到这个ACK包后，进入ESTABLISHED状态，而客户端也进入ESTABLISHED状态，此时连接已经建立。

通过三次握手，客户端和服务器能够建立起双向的通信连接。这种方式的设计可以保证连接的可靠性和可用性，因为每个阶段都需要一方确认对方的状态。如果在握手过程中某一次握手失败，连接将无法建立成功，通信双方可以根据超时时间来进行后续的重试。

三次握手过程中的每个步骤都有特定的目的： 1. 第一次握手：客户端发送SYN包给服务器，请求建立连接，并初始化客户端的序列号。

2. 第二次握手：服务器收到SYN包后，发送SYN-ACK包给客户端，确认客户端的SYN请求，并初始化服务器的序列号。

3. 第三次握手：客户端收到SYN-ACK包后，发送ACK包给服务器，确认服务器的SYN-ACK，并初始化客户端的确认序列号。

通过三次握手，双方能够互相确认对方的状态，并初始化自己的序列号和确认序列号。这样，在数据传输过程中双方就能够按照正确的顺序接收和发送数据，确保数据的可靠性和完整性。

需要注意的是，三次握手只是建立连接的过程，关闭连接时需要进行四次挥手。挥手的过程是为了确保数据在关闭连接时能够完全传输完毕，而不会丢失或被中途截断。

三次握手

三次握手

三次握手

[编辑本段]

三次握手-简介

所谓的“三握手”：对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据 量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。为了提供可靠的传送，TCP 在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。TCP 总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。

[编辑本段]

三次握手-释意

TCP握手协议

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个ASK包（ask=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

三次握手协议

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：

未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

Backlog参数：表示未连接队列的最大容纳数目。

SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。

浅探网络1---tcp协议详解（三次握手和四次挥手）

浅探网络1---tcp协议详解（三次握手和四次挥手）

浅探⽹络1---tcp协议详解（三次握⼿和四次挥⼿）

TCP协议是⽹络多层协议中运输层的最重要的协议之⼀，运输层是两台主机的进程之间的通信。除了TCP还有⼀个是UDP协议（⽤户数据包协议）TCP全称是Transmission Control Protocol，意思是传输控制协议

⼀、TCP简介

1.TCP协议两个对等运输实体之间进⾏传送的数据单位是：TCP报⽂段

2.TCP提供的是⾯向连接的服务，在传送数据之前必须建⽴连接，数据传送完成之后需要关闭连接，TCP只可点对点，不可⼴播或多播，TCP连接是可靠的运输服务。3.TCP的⼯作⽅式类似于打电话，打电话之前需要先拨号（号码就是连接的IP+端⼝号）连接，通话结束之后关闭连接

4.TCP提供可靠交付，即TCP传输的数据⽆差错、不丢失、不重复且有序

5.TCP⽀持全双⼯通信，即通信双⽅可随时发送数据，发送⽅发送完数据会先放到发送缓存中，发送⽅发送完毕就可以⼲别的事去了，TCP会在合适的时机将数据发送给接受⽅，接收⽅接收到数据会先把数据放到接收缓存中，应⽤程序会在合适的时机在缓存中获取数据。6.TCP是⾯向字节流的，流⼊到进程或从进程中流出的是字节序列。⽽发送时和接收时除了传输的业务数据，可能还会额外加⼀些字节数据，⽤于发送⽅和接收⽅处理。⽐如在微信聊天中需要提醒接收⽅会添加@XXX，⽽接收⽅只需要接收有⽤信息，@信息是和业务⽆关的。7.TCP连接的双⽅不是两个主机、不是两个IP地址、不是两个应⽤程序、⽽是两个套接字，每个套接字socket=（IP地址：端⼝号），每⼀个TCP连接必须有唯⼀的两个套接字，即TCP连接={套接字1，套接字2}={（IP1，port1），（IP2，port2）}

⼆、TCP三次握⼿和四次挥⼿

TCP是⾯向连接的协议，所以协议的基础就是需要有连接，⽽发起连接的⼀⽅可以称为客户端，等待连接的⼀⽅可以称为服务端。⽽TCP建⽴连接的过程称为握⼿，每次握⼿客户端和服务器之前需要交换三个报⽂段，因此也叫做“三次握⼿”。

TCP—— SYN、ACK 、FIN、RST、PSH、URG 详解

TCP—— SYN、ACK 、FIN、RST、PSH、URG 详解

三次握手Three-way Handshake

一个虚拟连接的建立是通过三次握手来实现的

1. (B) --> [SYN] --> (A)

假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize)

标记的包，告诉A请求建立连接.

注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不能让外部任何主机主动建立连接。

2. (B) <-- [SYN/ACK] <--(A)

接着，A收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.

注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.

3. (B) --> [ACK] --> (A)

B收到SYN/ACK 包,B发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成

Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位

这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包

四次握手Four-way Handshake

四次握手用来关闭已建立的TCP连接

1. (B) --> ACK/FIN --> (A)

2. (B) <-- ACK <-- (A)

3. (B) <-- ACK/FIN <-- (A)

4. (B) --> ACK --> (A)