面向数据连接:TCP(下)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 面向数据连接:TCP(下)

产生TCP ACK的情况及其 建议


image.png


快速重传


就是在快速定时器超时之前已经收到了某个段的冗余ACK, 那么就需要在某个段还没有到时的情况下,将这个段快速重新传出去 ,而不是等待它超时了再进行重传。


  • 超时周期往往太长:
  • 在重传丢失报文段之前的 延时太长
  • 通过重复的ACK来检测 报文段丢失
  • 发送方通常连续发送大量 报文段
  • 如果报文段丢失,通常会 引起多个重复的ACK


如果发送方收到同一数据 的3个冗余ACK,重传最 小序号的段:


==快速重传:在定时器过时 之前重发报文段==


它假设跟在被确认的数据 后面的数据丢失了


• 第一个ACK是正常的;


• 收到第二个该段的ACK,表 示接收方收到一个该段后的 乱序段;


• 收到第3,4个该段的ack,表 示接收方收到该段之后的2个 ,3个乱序段,可能性非常大 段丢失了


1691203654137-4c2fdaed-b2be-471e-b159-23edd96a66cb.png


快速重传算法:

event: ACK received, with ACK field value of y
    if (y > SendBase) {
    SendBase = y
    if (there are currently not-yet-acknowledged segments)
      start timer
  } 
else {  //已确认报文段的一个重复确认
    increment count of dup ACKs received for y
    if (count of dup ACKs received for y = 3) { //快速重传
      resend segment with sequence number y
}


流量控制


目的就是防止发送方发送的太快, 而使得接收方得缓冲区溢出。


1691203747872-3466fc8b-df52-4a67-b847-bb020fc3636f.png


  • 接收方在其向发送方的TCP段 头部的rwnd字段“通告”其空 闲buffer大小


  • RcvBuffer大小通过socket选项 设置 (典型默认大小为4096 字 节)
  • 很多操作系统自动调整 RcvBuffer
  • 发送方限制未确认(“inflight”)字节的个数≤接收 方发送过来的 rwnd 值


  • 保证接收方不会被淹没


1691203797706-221a0abf-9b7b-4386-9cb8-4bff7c5fc12e.png


TCP流量控制


相当于木桶效应, 即使发送方能够发送4096bit得数据。 但是接收方只能接收1080bit的数据, 那么发送方也只能有效发出1080bit的数据。

1691204351596-f4d13481-07f7-4b4e-b692-06646149e8a9.png

连接管理


连接的本质:


  1. ==双方都知道要和对方通信==
  2. ==双方要为通信连接准备好必要的资源(初始序号等)==
  3. ==控制变量需要做置位(序号、初始化receiveBuffer(接收窗口)大小等都需要告诉对方)==*


在正式交换数据之前,发送方和接收方握手建立通信关系:


  • 同意建立连接(每一方都知道对方愿意建立连接)
  • 同意连接参数


为连接做 准备

1691205012180-7194692d-5f3e-4a90-b9db-e4d4c8306e2e.png


两次握手建立连接的不可行性


1691205076751-a1d6c40d-6499-4694-a848-9425669fc2fb.png


  1. 变化的延迟(连接请求的段 没有丢,但可能超时)
  2. 由于丢失造成的重传 (e.g. req_conn(x))
  3. 报文乱序
  4. 相互看不到对方


2次握手失败的场景:


1691205114081-7cc947ac-dd82-4f20-bc9d-dc2395e6496d.png


Client发送了建立连接的请求, 然后Server收到连接请求, 并且进行了确认, 然后发送给了Client 。Client接收到了Server的连接确认, 表示Client知道Server是活跃的, 但是之后Client并没有继续发送确认信息。 因为握手已经结束, 所以Server并不知道你Client是否活跃,所以这就是所谓的半连接。


TCP 三次握手


基于2次握手的不可行性, 我们通过三次握手来实现解决。


基本方案是 : 变化的初始序号+双方确认对方的序号(3次握手)


1691205139715-704290ba-f75c-4a91-b636-8d64473048fc.png


1.Client建立起连接 。然后将自己的初始序号, x发送TCP SYN报文。

SYN = 1 就是连接请求, Seq = x 就是告诉对方,我将要从x这个字节开始传输。(x就是初始序号)


2.Server接收到连接请求 ,发出连接确认。

SYN = 1 表示连接请求, Seq = y 就是告诉Client我要从y这个字节开始传输(y就是server的初始序号)


ACK =1 表示我确认接收到了连接请求,ACKNum 表示我确认接收到了x的请求 ,希望你下次从x+1开始传输


3.Client接收到了第二次握手的信号,发出第三次握手

接收到SYN = 1 表示Server是活跃的, 发送SYNACK 的ACK表示 该报文可能包含C-S的数据


接收到了Server的初始序号Seq = y, 本次我就要确认Server给的初始序号。


并且发送ACK = 1表示Client确认了这次的请求。ACKNum = y+1 表示我确认接收到了y的请求 ,希望你下次从y+1开始传输


4.Server接收到Client的确认请求。

ACK(y)表示Client是活跃的。


通常第三次握手跟第一次的数据传递是放在一块的。


3次握手解决:半连接和接收老数据问题


1691205213999-19a09ccf-1771-4484-b3be-6ef8253a5b55.png

因为三次握手首先需要将初始序号(x)告诉对方, 然后收到对方的确认之后, 再进行后续的传输,如果说client本次传输的序号不是(x+1) 那么Server就会refuse。 就不会出现老数据传输


TCP 三次握手 : FSM


1691205245742-c410c9b1-4cb7-4bef-8e60-3e1c4386a0f8.png


TCP: 关闭连接


  1. 客户端,服务器分别关闭它自己这一侧的连接【通过发送FIN bit = 1的TCP段 】
  2. 一旦接收到FIN,用ACK回应 【 接到FIN段,ACK可以和它自己发出的FIN段一起发 送
  3. 可以处理同时的FIN交换


1691205335826-de28ed01-fc56-40da-9fcf-aeecdc442062.png

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2月前
|
网络协议 算法 Linux
TCP教程:详解TCP连接过程
TCP教程:详解TCP连接过程
432 0
|
2月前
|
网络协议
TCP和UDP和端口
TCP和UDP和端口
31 1
|
2月前
|
网络协议 算法 安全
TCP 连接建立
TCP 连接建立
43 0
|
11月前
|
网络协议
建立TCP的连接的三次握手
刚才咱们一起学了四次挥手,这来看看三次握手!
55 1
|
11月前
|
网络协议 安全 网络性能优化
面向数据连接:TCP(上)
面向数据连接:TCP(上)
149 0
|
网络协议
TCP建立连接的三次握手
看了点网络的书,回顾下TCP的连接细节,记一下
175 0
TCP建立连接的三次握手
|
缓存 网络协议
TCP连接的 三次握手
TCP连接的 三次握手
|
网络协议 网络安全
TCP连接与防火墙
通常,我们的Tcp服务器会放在IDC机房的某一个或几个防火墙后面,客户端与服务器之间的TCP连接会经过防火墙中转,如下图所示:          在这种情况下,有一点特别需要注意:当Firewall与Server之间的Tcp连接在一段时间(如10分钟)内没有任何应用层的消息经过时,Firewall可能会主动断开与Server之间的Tcp连接,但是Client与Firewall之间的连接一直是有效的。
888 0
|
网络协议
tcp建立连接为什么需要三次握手
这是一个看似很“简单”的问题,但貌似并没有一个官方统一的答案。搜索了相关的资料,列举出一些答案。 以下部分转载自:tcp建立连接为什么需要三次握手 在《计算机网络》一书中其中有提到,三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误”,这种情况是:一端(client)A发出去的第一个连接请求报文并没有丢失,而是因为某些未知的原因在某个网络节点上发生滞留,导致延迟到连接释放以后的某个时间才到达另一端(server)B。
1070 0