详解TCP协议

最新推荐文章于 2024-07-12 14:20:33 发布
最新推荐文章于 2024-07-12 14:20:33 发布
阅读量541 收藏
点赞数
文章标签： tcp/ip 网络 网络协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_20963687/article/details/131714603
版权

TCP协议段格式

在这里插入图片描述

  • 序号和确认序号：在真实服务器和客服端通信过程中请求是并行执行的，这会导致到达是乱序的，所以才会有序号这个东西，确认序号是对方应答时返回的，例如序号发送到1，确认序号会返回2，表示2之前的都收到了（是连续的都收到了！）那为什么得专门分成序号和确认序号呢？因为是全双工的，client的序号和server的确认序号是一组，client的确认序号和server的序号是一组
  • 16位校验和: 发送端填充, CRC校验. 接收端校验不通过， 则认为数据有问题。此处的检验和不光包含TCP首部， 也包含TCP数据部分
  • 16位接收窗口：在真实通信中因为是并行的，对方的接收缓冲区可能被打满，我们需要得知对方的剩余接收缓冲区，这样就可以在全双工通信中实现流量控制
  • 6位标志位：

URG（带外数据）: 紧急指针是否有效，配合紧急数据指针来使用，起始位置（有效载荷）+16位紧急数据指针（偏移量），后面的1个字节为紧急任务，recv设置flag为MSG_OOB,send也把flag设置为MSG_OOB这样就可以发送和接收带外数据
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段，通信过程中，连接单方面出现问题，例如服务器挂了，但是client还认为连接存在，我们在请求时server把RST位设置为1，告诉对方需要重新建立连接
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

1.如何封装解包

TCP有标准长度，先读取前20字节，因为是一个结构化的数据，所以可以提取4bit首都长度，这个4bit表示tcp报头总长度，所以取值范围是[0000,1111]→[0,15]但是这不对啊，tcp报头最少20字节，所以默认要*4，[0,60]，因为最少是20，所以是[20,60]，这样就可以得到后续选项的长度，报头处理完毕以后，最后剩下的就是有效载荷了。

2.如何分用？

根据目的端口号，就可以找到应用层进程

细心的读者会发现，UDP的长度是包括有效载荷的长度，而TCP并没有，这也是为什么TCP是面向字节流的原因

3.收到一个报文，是如何找到曾经bind特定port的进程的？

利用哈希可以快速定位

确认应答（ACK）机制

在这里插入图片描述

每一个ACK都带有对应的确认序列号， 意思是告诉发送者， 我已经收到了哪些数据; 下一次你从哪里开始发

超时重传机制

情况一：

在这里插入图片描述

情况二：

在这里插入图片描述

因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果

重点：发送端，发出的数据必须要被维持一段时间，收到应答之后才可以删除！

超时时间规则如下：

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”
但是这个时间的长短, 随着网络环境的不同, 是有差异的
如果超时时间设的太长, 会影响整体的重传效率
如果超时时间设的太短, 有可能会频繁发送重复的包

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传
如果仍然得不到应答, 等待 4500ms 进行重传.依次类推, 以指数形式递增
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

连接管理机制

在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接

三次握手：

在这里插入图片描述

学了上面的东西，我们在重新理解一下这个过程，这里的SYN和ACK的设置就是更改报头的ACK和SYN标志位

四次挥手：

在这里插入图片描述

主动断开连接的一方，最终状态时TIME_WAIT，四次挥手动作已经完成，但是主动断开连接的一方要维持一段时间（2*MSL）的TIME_WAIT，为什么要维持这个状态？1.保证最后一个ACK尽可能被收到 2.双方在断开连接时，网络中还有滞留的报文——保证滞留报文消散

被动断开连接的一方，两次挥手完成是CLOSE_WAIT状态，可以通过不close服务端显示出这种情况

1.学了以上知识我们就可以解释为什么服务器会bind失败?

答：服务器是主动断开连接的一方，它会处于TIME_WAIT状态，而处于这个状态时，该端口和连接依旧被占用，所以无法bind

2.解决bind失败的方法

在这里插入图片描述

流量控制

前文我们知道TCP协议段格式中有一条叫做窗口大小，这个就是负责流量控制的，以免发送速度过慢或者过快。

1.我们如何第一次就知道对方缓冲区的大小的呢？

在通信之前，我们就做过了三次握手，交换窗口大小
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端

2.接收端如何把窗口大小告诉发送端呢?

回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位;

滑动窗口

在这里插入图片描述

滑动窗口的大小是变化的！滑动窗口大小=min（对方的接收缓冲区，拥塞窗口），可能变大也可能变小

1.数据没丢，只是应答丢失了

在这里插入图片描述

2.数据真的丢了

如上图，那么就是应答错误的那个序号，滑动窗口不会向后滑动，连续收到3个包括3个就会触发重传机制

以上我们讨论的都是端到端的情况，也就是说我们讨论的都是双方的问题，没有考虑到网络的问题，所以就会有拥塞控制

拥塞控制

虽然TCP有了滑动窗口这个大杀器， 能够高效可靠的发送大量的数据。 但是如果在刚开始阶段就发送大量的数据， 仍然可能引发问题。因为网络上有很多的计算机， 可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下， 贸然发送大量的数据，是很有可能引起雪上加霜的

TCP引入慢启动机制， 先发少量的数据， 探探路， 摸清当前的网络拥堵状态， 再决定按照多大的速度传输数据。

此处引入一个概念程为拥塞窗口。发送开始的时候， 定义拥塞窗口大小为1。每次收到一个ACK应答, 拥塞窗口*2。每次发送数据包的时候， 将拥塞窗口和接收端主机反馈的窗口大小做比较， 取较小的值作为实际发送的窗口。

像上面这样的拥塞窗口增长速度， 是指数级别的。 “慢启动” 只是指初使时慢， 但是增长速度非常快。
为了不增长的那么快， 因此不能使拥塞窗口单纯的加倍，此处引入一个叫做慢启动的阈值，当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

在这里插入图片描述

  • 当TCP开始启动的时候, 慢启动阈值等于窗口最大值
  • 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

数量限制: 每隔N个包就应答一次;
时间限制: 超过最大延迟时间就应答一次

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端

面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

  • 调用write时, 数据会先写入发送缓冲区中;
  • 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
  • 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
  • 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
  • 然后应用程序可以调用read从接收缓冲区拿数据;
  • 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节; 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

TCP异常情况

  • 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
  • 机器重启: 和进程终止的情况相同.
  • 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释

TCP总结

可靠性:

校验和
序列号(按序到达)
确认应答
超时重发
连接管理
流量控制
拥塞控制

提高性能:

滑动窗口
快速重传
延迟应答
捎带应答

其他:

定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)

基于TCP应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP

学完以上知识，请问如果想用UDP实现可靠传输该怎么做呢？

1.引入序列号，保证数据顺序 2.引入确认应答 3.引入超时重传 等

listen第二个参数

listen(int socket, int backlog);

第二个参数backlog代表等待队列的最大长度

在这里插入图片描述

客户端：

当connect到来的时候无论等待队列有没有空余地方在客户端眼里都是连接成功的，因为一开始调用connect函数SYN请求，服务端立刻给予客户端SYN＋ACK确认，客户端连接状态从SYN_SENT转换到ESTABLISHED之后再向服务端发ACK确认。也就是所谓的三次握手过程

服务端：

当客户端connect来到时，服务端进入SYN_RCVD状态并给予SYN＋ACK响应。当下次客户端完成三次握手，收到客户端的ACK时：如果队列中有空间，则服务端的连接也建立成功，否则服务端眼里没有成功。每建立成功一次，要往队列中放入刚才建立好的连接，也就是队列空间－1，服务端状态从SYN_RCVD变为ESTABLISHED，如果不成功还是原来的SYN_RCVD状态。当服务端调用accept成功时，又是队列空间＋1，从队列中拿走一个连接。

Linux内核协议栈为一个tcp连接管理使用两个队列:

  1. 半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）
  2. 全连接队列（accpetd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）

而全连接队列的长度会受到 listen 第二个参数的影响。全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了。这个队列的长度是 listen 的第二个参数 + 1。

测试：

把listen的第二个参数设置为1，并且把accept函数屏蔽掉，不让执行下去。这样保证迟早队列中会没有地方，导致有的连接不成功。

在这里插入图片描述

一共开了4个客户端，但从上图中可以看到只有两个服务端是成功的，另外两个还在上一个状态中，但是所有的客户端都是成功的。所以说明最大队列个数是backlog＋1。

努力敲代码的小王
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
python socket recv超时_socket为send和recv设置超时时间
weixin_42396502的博客
02-09 3205
linux和windows下用setsockopt设置SO_SNDTIMEO,SO_RCVTIMEO的参数的一点区别UDP的socket在某些情况：如对方关闭时，本地可能sendto不出去数据，然后recvfrom就会被阻塞，这时就需要设置 这两个参数的值提高程序质量。linux:struct timeval timeout={3,0};//3sint ret=setsockopt(sock_fd...
TCP/IP编程基础——超时、多路复用、非阻塞
weixin_30390075的博客
01-28 709
在TCP连接中，recv等函数默认为阻塞模式(block)，即直到有数据到来之前函数不会返回，而我们有时则需要一种超时机制使其在一定时间后返回而不管是否有数据到来，这里我们就会用到setsockopt()函数： int setsockopt(int s, int level, int optname, void* optval, socklen_t* optlen); 这里...
socket的send和recv的超时设置
码农code之路
02-25 2405
二、send的超时不会体现在对send函数的调用上，看msdn的解释：If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode.即只要协议栈缓冲区窗口没满，send就会成功。一、socket必须是阻塞类型的，否则设置超时毫无意义。
TCP 协议（四）重传与超时
cliffordl的专栏
07-12 3396
本博客从TCP重传、超时、拥塞控制、流量控制等方面进行了深入探讨，以帮助读者更好地理解TCP协议在网络传输过程中如何确保数据的可靠性和高效性。我们详细分析了各种重传原理、触发条件和优化策略，以及超时检测、动态调整和与重传的关系。同时，我们还探讨了拥塞控制与流量控制在调整网络传输速率、协同作用以确保网络稳定性的重要性。在实践中，我们针对不同的网络环境提供了优化策略，并对常见性能问题进行了分析和解决。此外，我们还展望了未来TCP重传与超时的发展趋势，为进一步提高网络性能提供了指导。
recv断网后阻塞-设置超时时间
GOODJOBLIKE的专栏
01-15 2128
struct timeval recv_timeout = {30,0};  setsockopt(CarInfosockfd,SOL_SOCKET,SO_RCVTIMEO,(char *)&recv_timeout,sizeof(struct timeval));
RECV的超时总结
冷月宫主的专栏
10-24 4489
说明:针对recv返回值，阻塞情况下，当网络异常时，recv是返回个-1，还是阻塞不动，还是根据情况而定呢 一、 不论是阻塞还是非阻塞都是 =0：连接关闭； >0接收到数据大小 二、 Recv 1、特别：返回值 2、只是阻塞模式下recv会阻塞着接收数据（非阻塞模式下如果没有数据会返回，不会阻塞着读，因此需要循环读取）。 阻塞情况下，阻
pythonTCP协议详解.doc
10-01
Python TCP 协议详解 TCP 协议（Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793 定义。它需要经过创建连接、数据传送、终止连接三个步骤。 一、TCP ...
详解TCP协议建立连接全过程状态变迁图.doc
08-22
本文将深入解析TCP协议建立连接的全过程，以及涉及到的状态变迁。 首先，TCP连接的建立始于客户端，它通过发送一个SYN（同步序列编号）段向服务器发起连接请求。此时，客户端进入SYN_SENT状态，表示已发送SYN但尚未...
Tcp协议协议详解
06-03
详细解读tcp/ip协议 对于互联网从业者非常重要，学好tcp协议对于网络编程是必须的
TCP协议详解_动力节点Java学院整理
10-19
TCP协议的核心特性包括： 1. 面向连接：在数据传输前，TCP需要通过三次握手建立连接，确保双方都能正常通信。连接的建立意味着双方都已经准备好并且分配了必要的资源，如缓冲区和定时器。 2. 可靠性：TCP通过...
recv、send函数windows下超时设置
mpp_king的博客
05-09 4333
点击打开原文链接    在socket通讯中，如果不设置超时时间的话，recv和send函数都会一直无限阻塞在那等待接受数据，为了防止出现这种情况，需要设置超时时间，windows下是这样设置超时时间。int recvTimeout = 30 * 1000; //30s int sendTimeout = 30 * 1000; //30s setsockopt(sClient, SOL_...
tcp_tw_reuse、tcp_tw_recycle 使用场景及注意事项
dbd379717的博客
12-07 255
linux TIME_WAIT 相关参数: net.ipv4.tcp_tw_reuse = 0 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭 net.ipv4.tcp_tw_recycle = 0 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭 net.ipv4.tcp_fin_t...
recv、send函数windows和linux下超时设置
gufeijunchi的专栏
11-27 8754
在socket通讯中，如果不设置超时时间的话，recv和send函数都会一直无限阻塞在那等待接受数据，为了防止出现这种情况，需要设置超时时间，windows下是这样设置超时时间 int recvTimeout = 30 * 1000;   //30s int sendTimeout = 30 * 1000;  //30s  setsockopt(sClient, SOL_SO
设置recv的超时
zqf_office的专栏
07-02 879
在TCP连接中，recv等函数默认为阻塞模式(block)，即直到有数据到来之前函数不会返回，而我们有时则需要一种超时机制使其在一定时间后返回而不管是否有数据到来，这里我们就会用到setsockopt()函数：     int  setsockopt(int  s, int level, int optname, void* optval, socklen_t* optlen);     这里
多线程实现TCP并发服务器使用setsockopt设置超时检测-使用setsockopt设置端口复用-传输层
qq_47355554的博客
05-24 1607
使用多线程实现TCP并发服务器代码实现服务器 使用setsockopt设置&getsockopt获取网络属性 网络超时检测
不开放80或443端口也能申请IP SSL证书！
最新发布
William1234er的博客
07-12 265
在申请SSL/HTTPS证书时，如果不方便使用域名或者没有域名，就要申请一种特殊的SSL证书——IP SSL证书。那么问题来了，有的实在不能开放80或者443端口，还能申请IP SSL证书吗？根据自身需求选择DV或者OV类型的IP地址证书，如果有算法要求也可自行选择（国际算法、国密算法、双算法），并下单支付相关费用，并填写IP地址的相关信息。验证通过后，CA机构就会签发证书（一般为几分钟），点击下载，解压证书文件包，并根据自身的Web环境进行安装部署！下面是具体的IP地址证书申请环节。
modbus tcp 协议详解
10-19
MODBUS TCP协议是一种基于TCP/IP协议的工业通信协议，它是MODBUS协议的一种变体。MODBUS TCP协议使用TCP/IP和链路层（以太网）校验和机制来校验分组交换的准确性，因此不需要像MODBUS RTU/ASCII协议那样使用CRC-16或LRC检查字段。MODBUS TCP协议支持多个独立的事务，可以在单一连接上进行多个请求和响应。此外，TCP允许很大数量的并发连接，因此在请求时重新连接或复用一条长的连接是发起者的选择。MODBUS TCP协议通常用于工业自动化领域，例如控制系统和传感器等设备之间的通信。 基于Python的ModbusTCP客户端实现详解，Modbus Poll和Modbus Slave是两款非常流行的Modbus设备仿真软件，支持Modbus RTU/ASCII和Modbus TCP/IP协议，经常用于测试和调试Modbus设备，观察Modbus通信过程中。如果你想深入了解MODBUS TCP协议，可以参考相关的文献和资料，例如MODBUS协议规范和MODBUS TCP协议规范等。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值