标签：协议 UDP ACK 报文 SYN TCP 发送 连接
TCP协议
传输协议TCP简介
- 面向连接,可靠的,基于字节流的传输层通信协议
- 将应用层的数据流分割成报文段并发送给目标节点的TCP层
- 数据包都有序号,对方收到则发送ACK确认,未收到则重传
- 使用校验和来检验数据在传输过程中是否有误
TCP报文头
- Source Port和Destination Port: 分别代表源端口(2B)和目的端口(2B)
- Sequence Number(seq): 占用4B,tcp字节流中每个字节都是按顺序去编号额,例如一个报文的序号字段值为107而携带的数据共有100个B(字段),如果有下一个报文段就应该由107+100即207开始
- acknowledge numbe: 占4B,期望收到对方下一个报文的第一个数据字节的序号,例： B 收到了A发送过来的报文，其序列号字段为301而数据长度是200字节，这表明B正确的收到了到序号301+200-1=500为止的数据，因此B期望收到A的下一个数据序号是501所以B在发送给A的确认报文中会把ack确认号置为501
- offset: 指出tcp报文的数据距离tcp报文的起始处有多远
- reserved: 保留域,保留今后使用的,但是目前都会标志为0
- tcp flag: 控制位,主要由8个标志位组成,每个标志位表示一次控制功能
- widow窗口: 指的是滑动窗口大小,用来告知接收端与发送端的缓存大小,以此控制发送端发送数据的速率从而达到流量控制
- check sum: 校验和,指的是奇偶校验,此校验和是对整个pct报文段,包括tcp头部,和tcp数据,以16位进行计算所得,由发送端计算和存储并由接收端进行验证
- urgent pointer: 紧急指针,只有tcp flags 中的 urg = 1时才有效.指出本报文段段中的紧急字节数
- TCP option: 可选项其长度可变，定义一些其他的可选参数。
TCP Flags
urg：紧急指针标志，1 有效，0 忽略。
ack：确认序号标志，1 表示确认号有效，0表示报文中不含确认信息。忽略确认号字段。
psh：push标志，1表示带有push标志的数据，指示接收方在接受到该报文段应尽快将报文段交给应用程序，而不是在缓冲区进行排队。
rst：重置连接标志，用于重置连接，或拒绝连接请求(用于处理连接中断）
syn：同步序号，用于建立连接过程 syn = 1 ack = 0 表示该数据段没有使用稍待的域，则连接应答稍待一个确认则syn=1 ack = 1
fin：finish标志，用于释放连接 1 表示发送方已经没有数据发送了 即关闭本方数据流。
TCP三次握手
当应用程序希望通过tcp与另一个程序通讯时,他会发送一个通信请求,这个请求必须被送到一个确切的地址,当双方握手之后tcp将在两个应用之间建立一个全双工即Full duplex的请求,这个全双工的通讯将占用两个计算机之间的通信线路,知道一方或双方关闭为止.
full duplex: 当A给B发送信息的同时,B也可以给A发送信息.
各个状态的意义如下：
LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
- 客户端发送SYN报文段请求连接报文(SYN=1,seq=x),此时客户端处于SYN-SENT,不能携带数据,服务端处于LISTEN；
- 服务器向客户端发送SYN+ACK报文段报文（SYN=1,ACK=1 ,seq =y,ack=x+1）,服务端处于SYN-RECIEVD,客户端处于SYN-SENT;
- 客户端向服务器发送ACK报文段（ACK=1,seq=x+1,ack=y+1）,此时客户端处于ESTABLISHED服务端处于ESTABLISHED
第一次握手：主机A发送位码为SYN=1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手，主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，SYN=1,ACK=1，随机产生seq number=7654321的包；
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ACK是否为1，若正确，主机A会再发送ack number=（主机B的seq+1）,ACK=1，主机B收到后确认seq值与ACK=1则连接建立成功。
- 为了初始化Sequence Number的值,在建立连接通信的时候,双方需要互相告知其Sequence Number并发送确认消息,确认双方可以建立连接通信
首次握手存在存在SYN超时的问题,Server收到Client的SYN,回复SYN-ACK的时候未收到ACK确认,Server不断重试直至超时,Linux默认5次,总共需要63秒断开连接.
此时即可使用SYN攻击(SYN Flood):建立大量的半状态连接,消耗CPU,内存,主机,路由器,网络资源.
针对SYN Flood的防护措施:
- SYN队列满后,通过tcp_syncookies参数回发SYN Cookies
- 若为正常连接则Clinet回发SYN Cookie,直接建立连接
另外针对建立连接后,Client出现故障也有一定的防护措施-----保活机制
- 向对方发送保活探测密文,如果未收到响应则继续发送
- 尝试次数到达keepAliveTime,仍未收到响应则中断连接
keepAliveTime:保活时间,用于测试连接在时间周期内是否活跃
TCP的滑窗
这里提供一个动态演示的链接
https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html
RTT：发送一个数据包到收到对应的ack，所花费的时间
RTO：重传间隔,定时器时间,如果回复了ack定时器失效,如果没有回复，RTO定时器的时间到了就重传,RTO是通过RTT计算出来的
TCP使用滑动窗口做流量控制与乱序重排
- 保证TCP的可靠性
- 保证TCP的流控特性
图示两个条框即发送端与接收端的缓冲区，都统一看作“从左往右”发送数据（写入缓冲区）或接受数据（从缓冲区读取）。
LastByteWritten指上层应用最新写入缓冲区要发送字节的位置
LastByteAcked指向收到的连续最大ack的位置（从最左端到此是已发送并收到回执的位置）
LastByteSent指向已发送的最后一个字节位置
LastByteRead指上层应用已读取接收的最后一个字节位置（已发送ACK回执)
LastByteExpected指已收到的连续最大的sequence的位置但还没发送回执
LastByteRcvd指已收到的最后一个字节的位置
还能够接受的窗口大小：AdvertisedWindow
还需要发送的窗口大小：EffectiveWindow
TCP滑窗可靠性，建立在确认重传基础上
发送方只有收到本段发送滑窗的ACK确认，才移动滑窗左边界
接收方只有在收到的数据ACK之后，才会移动滑窗左边界
接收方前面收到的数据未ACK，后面收到数据，不移动滑窗
确保发送放重传后面的数据。
滑窗大小可动态调整
TCP四次挥手
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KLny5L14-1643873617976)(D:\Note\详解\计算机网络\02.assets\image-20220203142147829.png)]
TCP 终止连接的四次挥手：
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进去FIN_WAIT_1状态
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1，Server进入CLOSE_WAIT状态
第三次挥手：Server发送一个FIN用来关闭Server到Client的数据传送，Server进入LAST_ACK状态
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手
原因:因为TCP是全双工的，所以发送方和接收方都需要FIN报文和ACK报文。即发送方和接收方各自两次挥手即可。只不过一方是被动，所以看上去像四次挥手。
原因:
- 确保有足够的时间让对放收到ACK包（如果被动关闭那方没收收到ACK,就会触发被动端重发FIN包，一来一去正好是两个msl）
- 有足够的时间让这个链接不会跟后面的连接混在一起。
原因:
- 对方关闭socket连接,我方忙于读或写,没有及时关闭连接
- 服务端收到客户端关闭请求，但未响应给客户端。
- 服务端有资源未释放，或者配置中线程池，连接数原因
**解决方式：**检查代码（释放资源的代码）和检查配置（处理请求的线程配置）
Linux查看服务器连接数命令：
netstat -n | awk '/^tcp/{++S[$NF]}END{for(a in S) print a,S[a]}'
UDP协议
1.source port 源端口
2.destination port 目标端口
3.length 数据包长度
4.checknumber校验值
5.data数据包
- 面向非连接
- 不维护连接状态，支持同时向多个客户机传输相同的消息
- 数据报头只有8个字节，额外开销较小
- 吞吐量只受数据生成效率，传输速率以及机器性能
- 不需要维持复杂的链接状态表。尽可能保证交付
- 面向报文，不对其报文进行拆分或合并，只负责获取
TCP和UDP的区别
- 面向连接vs无连接: tcp面向连接有三次握手的连接过程，udp无连接适合消息的多播发布，单个点向多个点传输
- 可靠性: tcp可靠（握手、确认、重传机制），udp不可靠
- 有序性: tcp利用序列号保证消息的顺序交互
- 速度: tcp速度慢，因为要创建连接，保证消息的可靠性和有序性
- 量级: tcp重量级，体现在元数据的头tcp20字节，udp八个字节
标签：协议,UDP,ACK,报文,SYN,TCP,发送,连接 来源： https://blog.csdn.net/weixin_43918614/article/details/122776399
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。