TCP 协议简述

TCP 协议简述

TCP允许以连接为导向的通信运输,即,在数据传递之前,必须建立连接,在数据传输完成后必须释放连接。

在向另一方提供数据之前,必须在双方之间建立任何方向的联系,在TCP/IP协议中,TCP协议提供可靠的连接服务,通过三次握手启动。
同时,由于TCP协议是连接的、可信赖的、以字节为基础的运输层通信协议,TCP是一种全时的复入模式,关闭连接需要四个顶替。

TCP包首部

发送到网络的数据包分为两部分:第一部分是拟使用的协议第一部分的一部分,另一部分是从上一层传输的数据,第一部分的结构按协议的特定标准详细叙述,第一部分清楚说明协议应如何阅读数据。

因此,在我们研究TCP议定书之前,我们必须首先了解TCP在网络传输中的位置和议定书的规范,然后我们将研究TCP最初网络传输的功能:

网络数据传输过程

以下图表是TCP头部的规范性说明,其中概述了TCP协议如何解读和分析数据:

TCP头部

以下信息载于TCP第一部分,是TCP协议所要求的:

• TCP端口号
  为了确定唯一的联系,TCP连接需要使用四个因素:
  (来源IP地址、源端口号)+(目的地IP地址、目的端口号)
  因此,TCP为储存保留了两个16位位的端口号,以前的IP协议提供了IP地址。
  来源港口和目的地港口各占16个字节,即港口范围为216 = 65535。
  该系统将其他1024个系统保留在下面,用户使用的港口范围为1024至65535。
• TCP的序号和识别号:
  32位序号:序列号后序号是TCP连接中传输方向中每个字节流的字节号,用于验证所传送数据的序列,例如,目前序列号是100,发送的100,下一个序列号是200。
  使用Acronymsack 32-bit确认号,即最近后序号的TCP确认号,作为对TCP段落的答复,在从TCP收到的序列号之后加上序列号。
• TCP的标志位
  每个TCP段落都有一个由TCP标记位置选项决定的单一功能,使发件人或接收人能够指定使用哪些符号,以便在另一端顺利处理该段落。
  SYN、ACK和FIN是用来建立连接、确认成功的部分转移和最终连接的最常见迹象。

1. SYN：简写为S同步建立会话连接和序列号所需的标志位置;
2. ACK：简写为.,识别标记,检查收到的数据包
3. FIN：简写为F,完成标记,表示我没有数据可以发送,并将断开连接;
4. PSH：简写为P如果另一方收到数据包,则必须将其送至最高层申请,而不是在缓冲区排队。
5. RST：简写为R链接签名槽,以重置、拒绝错误和非法数据包;
6. URG：简写为U(a) 紧急标记,这些标记表明,数据集中的紧急针头场是合法的,用来保证连接不被堵塞,并尽可能快地处理中间设备;

要连接,TCP握手必须进行三次。

三次握手(三向握手)是指在建立TCP连接时要求客户和服务器发出三条信息。

这三个握手器旨在将服务器连接到特定的端口,建立 TCP 连接,同步双方的序列号和确认号,并传递 TCP 窗口大小信息。在套接字程序里,客户程序运行连接 () 。 将启动三个握手程序 。

以下是三个握手过程的图表:

TCP通过“三向握手”(或“三向握手”)方法建立了连接,在连接建立期间必须初始化若干参数,如序列号,以确保相继传输和连接的复原力。

TCP 连接创建正常 。
两个终端可以同时启动连接。 但是, 大多数时候, 一端( 服务器端) 打开一个套接字( 套接字), 然后从另一个端( 客户端) 监听连接, 这个端被称为“ 被动打开 ” 。 在服务器端被被动打开后, 客户可以开始构建活动打开 。

在服务器客户端的监听功能之后,服务器上产生两个队列:

SYN队列第二个握手由存储器进行。倾听函数的参数反演决定队列的长度 。
ACCEPT队列存储完成了三次握手。 队列长度由监听功能的参数背对数决定 。

三次握手建立连接

• 第一次握手：
  客户端设置 TPCP 电文标签 SYN 到 1, 并随机生成序列值后继值 = J, 随机放置在带有序列号( 序列号) 字段的 TCP 第一部分, 识别客户端想要连接的服务器端口, 并将数据包传送到客户端进入的服务器端 。SYN_SENT状态正在等待服务器端的确认 。
• 第二次握手：
  当服务器收到数据包时,标签SYN=1明白客户请求连接,服务器将TPCP信息SYN和ACK设置为1,ack=J+1,随机生成序列值后继=K,并将数据包传送给客户以确认连接请求,服务器可以访问数据包。SYN_RCVD状态。
• 第三次握手：
  当客户端得到确认时, 请检查日志是否为 J+1 和 ACK 是 1, 如果是的话, 请将标记 ACK 设为 1, ack=K+1 并将数据包传输到服务器端, 检查日志是否为 K+1 和 ACK 是 1, 如果是的话, 请成功建立连接、 客户端和服务器访问 。ESTABLISHED三个握手已经完成,数据现在可以在客户端和服务器端之间传输。
• 如果服务器客户端收到客户端 SYN 并返回 SYN 并返回 SYN-ACK 客户端, 服务器没有收到客户端的 ACK, 连接处于中间状态, 没有成功也没有失败。 因此, 如果服务器客户端在一定时间内没有收到 TCP, SYN-ACK 将会重新发布。 在 Linux 下, 默认重试次数为 5 次, 重试间隔从 1 个开始翻一番, 5次重试之间的间隔为 1 2 、 2 、 4 、 8 、 8 16 个 、 共 31 和 32 个。 因此, 5次发布后, 共 5 重试之间的间隔为 1 + 2 + 4 + 8 + 8 + 32 + 32 = 63 用于 TCP 断开连接。 使用三个 TCP 参数来调整行为 : tcp_ synack_ retristries to retristries; tc_ max_ arrent_ translentsal_ translation.

据RFC 793称,“三握手”的目的是通过不可靠的渠道建立合法的通信联系,迫使双方相互告知各自集团的最初数目。

N. B. 我们和ACK讨论的不是同一件事:

• 小写杰克代表头号识别号, Acknollege 编号, Accryptic Jack, 前一个软件包序列号的编号, acq = after +1 。
• 大写ACK表示用于标记的TCP包件是否对前一个包件进行了验证,如果是的话,将ACK标记设为1。

我会做我自己的实验, 运行 HTTP 服务, 听80号港口, 然后用Tcpdump 的命令 来拿包和检查 TCP 的三个握手:

命令 tcpdump 拆卸构件 :
Enp0s3 是给定渔获的网卡 。
将域名转换为 IP 地址显示 。
-t: 不显示时间
-S:序号以绝对数字表示;如果不提供 -S,序号以相对数字表示。
端口: 指定的听众端口为 80 。
主机名: 您想要监听的主机名 。

在真正的战争中,我们检查TCP的三个握手过程:

• 当标志时代旗=S或SYN=1的标志发出请求,要求确定与服务连接时,同时制作序列号后序号=84689409,客户端港口51323开始连接服务器端口80。
• 第二手握、服务终端路标标志标记=[S],或SYN+ACK标记,设为1,表示确认先前的连接请求,同时设定 ACK=seq+1=184689410,创建序列号后序号为1893430205。
• 客户在第三次握手中承认服务方的回答,因此该标志是[.]。在退回先前序列的确认号后,ACK=1893 430206。 ]

所以有三个握手,一个TCP连接, 和两端传输。

为什么要握手三次?

我们假定客户发送的第一个链接请求信没有丢失,但Rither在网络节点停留了很长时间,推迟了连接放弃一段时间后到达服务器的时间。

但是,当服务器收到已停用的连接请求时,错误地认为这是客户再次提交的新的连接请求。 向客户发出了一份确认信,同意确定连接。

假设“ 三次握手” 没有被使用, 一旦服务器提供确认, 将立即形成新的连接。 但是, 由于客户尚未发出建立连接的请求, 它将不理会服务器的确认, 并且不会将数据传送到服务器。 结果, 服务器的许多资源被浪费了, 没有使用“ 三次握手”, 一旦服务器提供确认, 就会形成新的连接 。 但是, 由于客户尚未发出建立连接的请求, 它将不理会服务器的确认, 也不会将数据发送到服务器 。 结果, 服务器的许多资源被浪费了 。 结果, 许多服务器的资源被浪费了 。

因此,“三握手”战略可能避免发生这种情况。例如,在这种情况下,客户不会向服务器发送确认书,由于缺乏确认书,服务器理解客户没有寻求连接。

TCP的三个握手与现实生活中的电话交谈相当相似:

三次握手：
"你好,你能听到我在说什么吗?"
"你听得到我说话吗? 我能听到你说话吗?"
"巴拉巴拉,我今天能听见你.."

在三次相互确认后,推定对方可以自言自语,并愿意进行下一次对话;否则,讨论可能终止。

TCP为结束连接发出四次信号。

当 TCP 连接中断时, 共需要客户和用户验证断开连接的服务提供四个包。 在套接字程序程序中, 程序由客户或服务端执行关闭的用户启动 。
由于TCP连接是全时连接,每个方向都必须独立关闭,前提是当一当事方完成数据分发工作时,FIN被派来终止此方向的连接;获得FIN只是表示没有这方面的数据流动,即不再收到数据,但在FIN向该方向发送数据之前,仍然可以提供这一TCP连接的数据。主动关闭将由第一当事方进行,而被动关闭将由第二当事方进行。

以下是四个波过程的图表:

四次挥手关闭连接

Clitend 或 Serverend 可能已经开始了波波请求, 我们认为是由 Clitenend 发起的:

• Clieentend 启动波要求, 将路标传送到 FIN 服务器端口, 并设置序列号后序号, 当 Cliet 端进入时 。FIN_WAIT_1状态显示, Clitend 没有任何数据可以传送到服务器端 。
• 第二次分手:服务器收到了来自Clitend的FIN信息, 向Clitend, ACK的条目发送了一个路标, 在后方加上1, Clitend的条目上设置一个方形 。FIN_WAIT_2Serverend告知Clieentend,我承认并同意了你的停机请求。
• 第三次分手: FIN 的条目是服务器端向 Clitend 发送路标, 请求结束连接, 而 Clitend 也同时进入 。LAST_ACK状态。
• Clitend从服务器接收了 FIN 信息, 向服务器发送了 ACK 路标, 然后输入 Clitend 。TIME_WAIT此连接在服务器端收到 Clitend- end ACK 消息后立即终止。 此时, Clitenend 在等待 2MSL 后没有收到回复, 核实服务器端通常关闭, 结果 Clitenend 端可能关闭连接 。

为什么你要握手三次,如果你有联系 握手三次,如果你没有联系,握手四次?

建立连接是因为 SYN+ACK 消息在服务器从客户端收到 SYN 请求时可以直接发送。 使用 ACK 报告来回应, 使用 SYN 报告来同步。 因此, 仅用三次握手就可以建立连接 。

TCP是一种全时复入模式,因为它是连接的、可靠的、以字节为基础的运输层通信协议。
这意味着,当连接中断,而Clitendend发送了FIN部分时,它仅意味着Clitenend通知服务器数据已经发送。当服务器收到FIN信息并返回到ACK报告时,它注意到它知道没有从Clitendendend端发送数据,但服务器仍然可以将数据发送到Clitenendendend端,但服务器可能不会立即关闭SOCKET,直到数据也从服务器发送到SOCKET时,它仅仅意味着当连接中断,而Clitenend发送了FIN部分时,它意味着Clitenend通知服务器数据已经发送。当服务器收到FIN信息并返回到ACK报告时,它注意到它知道没有从Clitendendend端发送数据,但服务器仍然有可能将数据发送到Clitendendend端,它可能不会立即关闭SOCKET,直到数据也从服务器发送了数据。
当服务器端口也传输 FIN 部分时, 它表示没有数据可以发送; 它会通知 Clitend 我没有数据可以发送, 并且双方都乐意中断 TCP 连接 。

我们为什么要等2MSL?

MSL: 最大时间长度,这是在放弃之前在网络中存在任何说明的最长时间段。
有以下两个原因：

• 第二,确保TCP协议的全时运作连接安全关闭:
  由于IP协议不可靠或其他基于网络的原因,服务器没有从客户端获得ACK信息,如果客户端的结束连接此时终止,服务器端将在超时后重新发送FIN。CLOESD状态,使得重新启用的FIN无法发现正确的连接,导致连接中断,并阻止直接接触Clitend端提供的最后一个ACK。CLOSED状态，而要保持TIME_WAIT当它从FIN收到另一台接收器时,它确认对方收到ACK,然后适当结束连接。
• 第二,确保从网络中删除这一链接中重复的数据部分。
  如果 Clitend 发送最后一个 ACK 发送到CLOSED,它不能确保新连接的端口号与以前关闭的连接的端口号相同,即新连接可能使用前连接的端口号相同。如果前连接的任何数据仍留在网络中,则延迟数据在新连接完成后会到达Clitend港,而且由于新连接和旧连接的端口号和IP号相同,TCP协议认为延迟数据是新连接,而新连接将获得肮脏的数据,从而在数据包中造成混乱。

资源使用

当主机收到 TCP 软件包时, 使用两端的 IP 地址和端的端口号来确定该 TCP 软件包属于哪个会话。 使用一个表格来举行所有会话, 并指定 tcb 结构以包含源端端、 目的地端端口、 目的地 ip、 序列号、 回答号、 对应窗口大小、 主窗口大小、 tcp 状态、 tcp 输入/ 输出队列、 层输出队列、 tcp tcp tcp 的链接

服务器端的连接数量是无限的, 且仅受内存的限制 。 客户端连接的数量, 先前要求在将第一个 SYN 发送到服务器之前随机空闲端口的分配, 限制了客户端IP 地址的外部连接的最大数量 。 从 Linux 4. 开始使用选项 IP_ BIND_ ADRESS_ NO_ PORT, 它通知 Linux 内核不维护内部使用的临时端口, 端口号为 0,

收到但尚未读取的无法辨认的软件包和数据将使用操作系统的资源。

数据传输

一些基本技术确保了TCP在数据传输中的可靠性和可靠性,其中包括:使用序列号对收到的TCP电文进行分类并探测重复的数据;使用核实和检测信息错误,即非错误传输[3];使用确认和计时器检测和修复辍学或延误;流动管理(节流控制);抽搐控制(消毒控制);以及再传送。

可靠传输

1. 每个TCP报告段落通常包括一对序列号和确认号。 TCP电文的提供方称其字节流为序列号(安全号),另一方提供的字节号为确认号。 为了确保可靠性,TCP电文的接收方在收到一定数量连续的字节后发出确认。

2. TCP 层可使用序列号和确认号将收到的信息中的字节按正确的顺序发送到应用层。序列号是一个未签名的32位数号码,在返回零之前升至232-1。初始化序列号的选择是TCP中确保复原力和安全的关键操作。

3. TCP 协议使用序列号来识别在两端发送的字节的顺序,以便当收到另一端的数据时,可以重新设定序列,并交付或丢弃包件而无传输危险。在交付第一个包(SYN袋)之前,选择随机数字作为序列号的起始值,以防止 TCP 序列号预测袭击。

4. 向确认包(Acks)提供从另一方收到的字节流号,即确认号,以提醒另一方已成功收到数据流的字节位置。

5. 可靠性可识别丢失的传输数据,并通过发送者重复数据,包括超时(转播超时、RTO)和重复的累计确认(重复的累积概览,DupAcks)。

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/12727.html。