TCP第三次握手传数据过程图解

RFC793文档里带有SYN标志的过程包是不可以携带数据的,也就是说三次握手的前两次是不可以携带数据的(逻辑上看,连接还没建立,携带数据好像也有点说不过去)。重点就是第三次握手可不可以携带数据。

先说结论:TCP协议建立连接的三次握手过程中的第三次握手允许携带数据。

对照着上边的TCP状态变化图的连接建立部分,我们看下RFC793文档的说法。RFC793文档给出的说法如下(省略不重要的部分):

重点是这句 “Data or controls which were queued for transmission may be included”,也就是说标准表示,第三次握手的ACK包是可以携带数据。

首先, 第三次握手的包是由连接发起方(以下简称客户端)发给端口监听方(以下简称服务端)的,所以只需要找到内核协议栈在一个连接处于SYN-RECV(图中的SYN_RECEIVED)状态时收到包之后的处理过程即可。经过一番搜索后找到了,位于 net\ipv4目录下tcp_input.c文件中的tcp_rcv_state_process函数处理这个过程。如图:

这个函数实际上是个TCP状态机,用于处理TCP连接处于各个状态时收到数据包的处理工作。这里有几个并列的switch语句,因为函数很长,所以比较容易看错层次关系。下图是精简了无需关注的代码之后SYN-RECV状态的处理过程:

一定要注意这两个switch语句是并列的。所以当TCP_SYN_RECV状态收到合法规范的二次握手包之后,就会立即把socket状态设置为TCP_ESTABLISHED状态,执行到下面的TCP_ESTABLISHED状态的case时,会继续处理其包含的数据(如果有)。

上面表明了,当客户端发过来的第三次握手的ACK包含有数据时,服务端是可以正常处理的。那么客户端那边呢?那看看客户端处于SYN-SEND状态时,怎么发送第三次ACK包吧。如图:

tcp_rcv_synsent_state_process函数的实现比较长,这里直接贴出最后的关键点:

一目了然吧?if 条件不满足直接回复单独的ACK包,如果任意条件满足的话则使用inet_csk_reset_xmit_timer函数设置定时器等待短暂的时间。这段时间如果有数据,随着数据发送ACK,没有数据回复ACK。

之前的疑问算是解决了。

条件1:sk->sk_write_pending != 0

这个值默认是0的,那什么情况会导致不为0呢?答案是协议栈发送数据的函数遇到socket状态不是ESTABLISHED的时候,会对这个变量做++操作,并等待一小会时间尝试发送数据。看图:

net/core/stream.c里的sk_stream_wait_connect函数做了如下操作:

sk->sk_write_pending递增,并且等待socket连接到达ESTABLISHED状态后发出数据。这就解释清楚了。

Linux socket的默认工作方式是阻塞的,也就是说,客户端的connect调用在默认情况下会阻塞,等待三次握手过程结束之后或者遇到错误才会返回。那么nc这种完全用阻塞套接字实现的且没有对默认socket参数进行修改的命令行小程序会乖乖等待connect返回成功或者失败才会发送数据的,这就是我们抓不到第三次握手的包带有数据的原因。

那么设置非阻塞套接字,connect后立即send数据,连接过程不是瞬间连接成功的话,也许有机会看到第三次握手包带数据。不过开源的网络库即便是非阻塞socket,也是监听该套接字的可写事件,再次确认连接成功才会写数据。为了节省这点几乎可以忽略不计的性能,真的不如安全可靠的代码更有价值。

条件2:icsk->icsk_accept_queue.rskq_defer_accept != 0

这个条件好奇怪,defer_accept是个socket选项,用于推迟accept,实际上是当接收到第一个数据之后,才会创建连接。tcp_defer_accept这个选项一般是在服务端用的,会影响socket的SYN和ACCEPT队列。默认不设置的话,三次握手完成,socket就进入accept队列,应用层就感知到并ACCEPT相关的连接。当tcp_defer_accept设置后,三次握手完成了,socket也不进入ACCEPT队列,而是直接留在SYN队列(有长度限制,超过内核就拒绝新连接),直到数据真的发过来再放到ACCEPT队列。设置了这个参数的服务端可以accept之后直接read,必然有数据,也节省一次系统调用。

SYN队列保存SYN_RECV状态的socket,长度由net.ipv4.tcp_max_syn_backlog参数控制,accept队列在listen调用时,backlog参数设置,内核硬限制由 net.core.somaxconn 限制,即实际的值由min(backlog,somaxconn) 来决定。

有意思的是如果客户端先bind到一个端口和IP,然后setsockopt(TCP_DEFER_ACCEPT),然后connect服务器,这个时候就会出现rskq_defer_accept=1的情况,这时候内核会设置定时器等待数据一起在回复ACK包。我个人从未这么做过,难道只是为了减少一次ACK的空包发送来提高性能?哪位同学知道烦请告知,谢谢。

条件3:icsk->icsk_ack.pingpong != 0

pingpong这个属性实际上也是一个套接字选项,用来表明当前链接是否为交互数据流,如其值为1,则表明为交互数据流,会使用延迟确认机制。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • TCP/IP协议中三次握手四次挥手的原理及流程分析

    当初学的是通信专业,毕业以后,同学们各奔东西,去追逐自己的梦想,奔波于大大小小的工地之间.哈哈,开个玩笑,也有厉害的,进了某某研究所,嗯?他爸不是所长,内心不要太阴暗.记得有一门十分高大上的课程,名字叫做计算机网络(大概是这个名字吧).里面有一个关于握手的概念,现在温习一下. 先来看看原理图: TCP是面向连接的,无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接.在TCP/IP协议中,TCP 协议提供可靠的连接服务,连接是通过三次握手进行初始化的.三次握手的目的是同步连接双方的序列

  • TCP性能调优实现原理及过程解析

    三次握手阶段 客户端SYN包的重试次数 sysctl -w net.ipv4.tcp_syn_retries=6 相关介绍 第 1 次重试发生在 1 秒钟后,接着会以翻倍的方式在第 2.4.8.16.32 秒共做 6 次重试,最后一次重试会等待 64 秒,如果仍然没有返回 ACK,才会终止三次握手.所以,总耗时是 1+2+4+8+16+32+64=127 秒,超过 2 分钟. 服务端半连接池大小 sysctl -w net.ipv4.tcp_max_syn_backlog=16384 服务端半连

  • TCP socket SYN队列和Accept队列区别原理解析

    首先我们必须明白,处于"LISTENING"状态的TCP socket,有两个独立的队列: SYN队列(SYN Queue) Accept队列(Accept Queue) 这两个术语有时也被称为"reqsk_queue","ACK backlog","listen backlog",甚至"TCP backlog",但是这篇文章中我们使用上面两个术语以免造成混淆. SYN队列 SYN队列存储了收到SYN包的连

  • TCP的三次握手与四次挥手详细介绍

    TCP的三次握手与四次挥手详细介绍 为什么是三次握手? 目的:防止已失效的连接请求又传到了服务器端. 场景(A为客户,B为服务器):A向B发送一个请求连接报文,但是这个报文在网络中阻塞了,并没有传到B.所以B也无法向A发送确认报文,在A的重传计时器到达之后,A再次向B发送请求连接报文,这个报文B收到了,并且向A做出应答,建立连接,传输数据.数据传输完后,关闭连接.问题来了,就在B关闭连接之后,A第一次发送的请求连接报文到了(这个报文是已经失效的),B以为A要再次创建一个新连接,于是向A发送确认报

  • 基于python模拟TCP3次握手连接及发送数据

    源码如下 from scapy.all import * import logging logging.getLogger('scapy.runtime').setLevel(logging.ERROR) target_ip = '192.168.1.1' target_port = 80 data = 'GET / HTTP/1.0 \r\n\r\n' def start_tcp(target_ip,target_port): global sport,s_seq,d_seq #主要是用于TC

  • TCP三次握手及原理

    TCP/IP是很多的不同的协议组成,实际上是一个协议组,TCP用户数据报表协议(也称作TCP传输控制协议,Transport Control Protocol.可靠的主机到主机层协议.这里要先强调一下,传输控制协议是OSI网络的第四层的叫法,TCP传输控制协议是TCP/IP传输的6个基本协议的一种.两个TCP意思非相同. ).TCP是一种可靠的面向连接的传送服务.它在传送数据时是分段进行的,主机交换数据必须建立一个会话.它用比特流通信,即数据被作为无结构的字节流. 通过每个TCP传输的字段指定顺

  • Java基于TCP协议socket网络编程的文件传送的实现

    先了解一下socket基本概念 socket也叫套接字: 是指在网路中不同主机上的应用进程之间,进行双向通信的端点的抽象. 简单理解就是: 两个主机之间要通信,就需要知道彼此的ip,端口号等信息,而一台主机这些信息的集合: 就可以理解为一个端点,即为套接字 双方通过套接字作为一种坐标,建立信息通道,形成连接(两点连接一条直线) 简单理解了套接字的概念后,来看看如何通过java socket编程来实现 两台主机文件的接收与发送: 代码如下: 发送方: import java.io.*; impor

  • Wireshark基本介绍和学习TCP三次握手

    这篇文章介绍另一个好用的抓包工具wireshark, 用来获取网络数据封包,包括http,TCP,UDP,等网络协议包. 记得大学的时候就学习过TCP的三次握手协议,那时候只是知道,虽然在书上看过很多TCP和UDP的资料,但是从来没有真正见过这些数据包, 老是感觉在云上飘一样,学得不踏实.有了wireshark就能截获这些网络数据包,可以清晰的看到数据包中的每一个字段.更能加深我们对网络协议的理解. 对我而言, wireshark 是学习网络协议最好的工具. 阅读目录 wireshark介绍 w

  • Java 基于tcp协议实现文件上传

    服务端 package lesson02; import java.io.*; import java.net.ServerSocket; import java.net.Socket; /** * 服务端接收文件 */ public class TcpServerDemo2 { public static void main(String[] args) throws IOException { //1.创建服务 ServerSocket serverSocket = new ServerSo

  • TCP第三次握手传数据过程图解

    RFC793文档里带有SYN标志的过程包是不可以携带数据的,也就是说三次握手的前两次是不可以携带数据的(逻辑上看,连接还没建立,携带数据好像也有点说不过去).重点就是第三次握手可不可以携带数据. 先说结论:TCP协议建立连接的三次握手过程中的第三次握手允许携带数据. 对照着上边的TCP状态变化图的连接建立部分,我们看下RFC793文档的说法.RFC793文档给出的说法如下(省略不重要的部分): 重点是这句 "Data or controls which were queued for trans

  • 两张动图--带你搞懂TCP的三次握手与四次挥手

    目录 TCP的概述 TCP报文首部 TCP连接的建立(三次握手) 什么TCP客户端最后还要发送一次确认呢? TCP连接的释放(四次挥手) 为什么客户端最后还要等待2MSL? 如果已经建立了连接,但是客户端突然出现故障了怎么办? 总结 背景描述 通过上一篇中网络模型中的IP层的介绍,我们知道网络层,可以实现两个主机之间的通信.但是这并不具体,因为,真正进行通信的实体是在主机中的进程,是一个主机中的一个进程与另外一个主机中的一个进程在交换数据.IP协议虽然能把数据报文送到目的主机,但是并没有交付给主

  • Jmeter使用接口传递数据过程图解

    一. 1.提取响应结果中的"mobile_phone",作为下一个登录接口的账号信息 1)在当前接口下,添加-置处理器-正则表达式提取器 2)正则表达式处理器 说明: 后置处理器:在请求结束或者返回响应结果时发挥作用 APPly to:作用范围(返回内容的断言范围) Main sample and sub-samples:作用于父节点的取样器及对应子节点的取样器 Main sample only:仅作用于父节点的取样器 Sub-samples only:仅作用于子节点的取样器 JMet

  • 计算机网络传输协议TCP三次握手与四次挥手原理

    目录 TCP三次握手四次挥手 服务器状态转换 客户端状态转换 TCP状态转换图 TCP中常见的面试题 为什么是三次握手,不是一次或者两次 为什么是三次握手,四次挥手 如果已经建立了连接,但是客户端突然出现故障了怎么办? 为什么会有TIME_WAIT状态 我们来想一想,为什么TIME_WAIT的时间是2MSL 解决TIME_WAIT状态引起的bind失败的方法 TCP三次握手四次挥手 我们之前在 传输层协议TCP与UDP中详细介绍了UDP协议和TCP协议格式以及他们各自的特点,我们知道TCP协议是

  • 详解PHP Swoole与TCP三次握手

    握手常见问题 1.连接拒绝 2.Operation now in progress 多是因为丢包.错误ip.backlog满了&阻塞&tcp_abort_on_overflow=0 3.min(maxconn, backlog) ss -lt 连接拒绝 在TCP三次握手的时候,客户端发送SYN这个包给服务端,服务端不接受这个请求,操作系统直接返回了一个RST的包,来拒绝连接的请求. 最常见的情况就是客户端去请求某个服务器,服务端没有绑定对应的端口. 测试代码如下,服务端代码: <?p

  • python flask框架实现传数据到js的方法分析

    本文实例讲述了python flask框架实现传数据到js的方法.分享给大家供大家参考,具体如下: 首先要清楚后台和前端交互所采用的数据格式. 一般选JSON,因为和js完美贴合. 后台返回的数据进行序列化 在/homepageRecommend 路由的 view方法中返回序列化数据 dict = {"a":1, "b":2}<br data-filtered="filtered"> import json json.dumps(di

随机推荐