ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

网络相关知识(TCP部分)

2021-04-15 21:01:50  阅读:244  来源: 互联网

标签:报文 知识 确认 网络 TCP 发送 服务端 客户端


七层协议和TCP/IP协议簇

OSI七层协议和Tcp/ip四层协议

 

 

 

 

应用层:应用程序间通信规则

  • DNS:建立ip地址和域名之间关系
  • Telnet:远程管理协议,是不安全的,与此相对SSH是安全的
  • FTP:传文件的协议
  • HTTP:超文本传输协议

传输层(TCPIP中的TCP):端到端的数据传输服务

  • TCP:面向连接的,可靠的数据传输服务
  • UDP:无连接的数据传输服务,不保证传输可靠性

网络层(TCPIP中的IP):点到点的数据传输

数据链路层:数据帧

  • 以太网协议

物理层

 

TCP三次握手和四次挥手

 三次握手:

 

SYN:同步位 ACK:确认位 seq:序列号 ack:确认号  
  • 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
  • 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
  • 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

 

为什么需要三次握手

而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手:Client 什么都不能确认;Server 确认了对方发送正常,自己接收正常

第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:对方发送正常,自己接收正常

第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常,对方发送、接收正常

 

第二次握手为什么要传SYN和ACK两个

接收端传回发送端所发送的ACK是为了告诉客户端,我接收到的信息确实就是你所发送的信号了,这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。”

 

如果第三次握手客户端发的确认ack报文丢失,服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手

 

四次挥手

 

 

 

 

 举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束。

  • 第一次挥手:客户端向服务器发送一个带FIN标志位的报文
  • 第二次挥手:服务器向客户端发送一个带ACK标志位的报文。客户端到服务器的连接被关闭。
  • 中间可能服务器还会向客户端传数据
  • 第三次挥手:服务器向客户端发一个带FIN,ACK标志位的报文
  • 第四次挥手:客户端向服务器发一个带ACK标志位的报文
  • 客户端发出确认报文后不是立马释放TCP连接,而是要经过2MSL(最长报文段寿命的2倍时长)后才释放TCP连接。而服务端一旦收到客户端发出的确认报文就会立马释放TCP连接,所以服务端结束TCP连接的时间要比客户端早一些。

 

为什么TCP连接的时候是3次,关闭的时候却是4次?

只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了,服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了,但我服务端还有一些数据没发完,等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端,就是这里多出来了一次)。  

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接?

这里同样是要考虑丢包的问题,如果第四次挥手的报文丢失,服务端没收到确认ack报文就会重发第三次挥手的报文,这样报文一去一回最长时间就是2MSL,所以需要等这么长时间来确认服务端确实已经收到了。

 

 

TCP报文结构

 

 

 

TCPUDP区别

UDP不需要建立连接,虽然不可靠,但是速度快占用资源少。适用于QQ这种即时通讯

 

TCP如何保证可靠传输

 
  • 校验和:检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
  • 流量控制:TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 (TCP 利用滑动窗口实现流量控制)
  • 拥塞控制: 当网络拥塞时,减少数据的发送
  • ARQ协议: 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
  • 超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
 

ARQ协议

自动重传请求。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。   停止等待ARQ: 是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认(回复ACK)。如果过了一段时间(超时时间后),还是没有收到 ACK 确认,说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组。   连续ARQ: 发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。    

滑动窗口--流量控制

流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。    

拥塞控制

和流量控制对比:流量控制是点到点。拥塞控制是整个网络。 慢开始 、 拥塞避免 、快重传 和 快恢复   先探测一下,由小到大增大发送窗口。        

标签:报文,知识,确认,网络,TCP,发送,服务端,客户端
来源: https://www.cnblogs.com/take-it-easy/p/14661501.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有