TCP/IP协议

1.计算机网络协议分层
在这里插入图片描述
相同层之间交互遵循协议,下一层为上一层服务,各层相互独立 ,互不影响,当修改每一层的内容时不会对其它层产生影响,每一层职责清晰,方便标准化。数据的传输是由应用层发起,经传输层为传输数据添加上协议报文,经网络层又添加上IP报文,最后经物理层传输数据。
2.TCP协议
传输层主要有两个协议:
TCP(传输控制协议):为应用层提供可靠的、面向连接的、基于流的服务。
UDP(用户数据报协议): 为应用层提供不可靠、无连接、基于数据报的服务。
TCP协议是面向连接的可靠(超时重传 , 确保数据能发送到目的端)的传输协议。tcp协议更关注传输控制层(传输层)以下的体系结构,其上囊括入应用层中
在这里插入图片描述
在这里插入图片描述

TCP报文结构:
来自b站牛兮兮的书发布的视频
TCP报文最少情况下所含字节数为20(即没有附带可选项时)。
端口号用于标识应用层程序(取值范围为0~65535)
在这里插入图片描述
序列号:标识该条数据的编号。
确认号:表示收到对方所发数据的字节数或期望对方下次所发的序列号。(它的值往往是对方所发数据的序列号加上对方所发数据的字节大小,这为对方反应了收到数据的多少,体现了TCP的可靠性)(注:三次握手和四次挥手中SYN/FIN并不携带数据,确认号还是要在对方所发的序列号上加一,凡是需要对端的确认,一定消耗TCP报文的序列号)
保留位:暂未被使用,可能是提前为以后的某些更新留下位置。
标志位:保留位后面的大写字母部分。标黄的为常用标志位
在这里插入图片描述

三次握手:
客户端和服务端在进行数据传输之前需要建立TCP连接,三次握手后,可以建立连接。(TCP的面向连接)
在这里插入图片描述
为什么是三次?
三次握手让客户端和服务端都确保了自身的接收、发送没有问题。当服务器给客户端发送syn + ack时,客户端可以确定自身的接收、发送没有问题(服务器会向客户端发送握手反馈,说明客户端的握手请求成功发送,即客户端发送没有问题。而客户端能收到服务器的握手反馈,说明客户端的接收没有问题。)。对服务器来说也是同理 ,服务器需要收到客户端的一个反馈才能确保自身的接收没有问题。 这样客户端需要服务器的反馈,服务器需要客户端收到信息后的反馈,以及一开始客户端的握手请求一共就是三次握手了。

设备间的连接是可以一设备连多个设备的,那怎么区分哪些信息是哪个设备发的呢?
这时用到了socket [ip a + port a ip b + port b] 具有唯一性 改变其中的某项 可以建立新的连接

四次挥手:
设备间的数据传输结束后需要断开两设备的连接,释放两设备开辟的资源队列。
在这里插入图片描述

在这里插入图片描述
为什么需要四次?
按照三次握手的逻辑,四次挥手看似可以合成三次,即把服务器发送的消息合并为一条。但实际上并不能合并,因为服务器需要处理客户端发送来的各种请求,需要一定的时间,在服务器未处理出结果就立刻和客户端断开连接是不合适的,所以在收到客户端发送的分手请求时并不能马上回应确认断开连接,但如果不给客户端反馈的话,客户端又会超时重传(TCP的可靠连接机制)分手请求,所以服务器在收到客户端的分手请求时,需要先反馈确认收到,待完成连接需要完成的工作时再发送一个确认分手,客户端确认后才能断开连接,释放资源队列。所以四次才是合理的。

常见的一些其他相关问题:

  1. 半连接队列:三次握手时客户端发送SYN进入服务器的半连接队列中,等待三次握手完成。
  2. SYN Flood攻击:客户端伪造大量IP给服务器发送SYN包,服务端会将伪造IP纳入半连接队列并回复,并且等待回复,而半连接队列的容量是一定的,当伪造IP占满队列时正常的IP握手请求就得不到处理。
  3. TCP快速打开(TCP Fast Open ,TFO):TCP的扩展协议,在发送SYN包时就携带有要传的数据,不过它需要客户端之前和服务器三次握手过,并且服务器为客户端生成够cookie值,当客户端再次发送SYN时(携带有TCP cookie的请求),服务器校验cookie通过后发送SYN + ACK ,不用等待客户端的ACK便可以直接向客户端传数据,若校验cookie失败,则走正常的三次握手。
    在这里插入图片描述
    (优势:提高效率,可防止SYN Flood攻击,cookie通过后就不占用半连接队列了 )
  4. TCP报文中的时间戳的作用:在前面TCP报文中的可选项中可以加上发送时间戳和回显时间戳,有两个作用,(1)便于计算数据往返时延(在出现超时重传时,收到的回复不确定是对重传前的响应还是对重传后的响应,加上时间戳就能轻易解决这个问题),(2)解决序列号的回绕问题(TCP的序列号是用32bit来表示,而下一个序列号是在原序列号的基础上加上数据包大小,当序列号溢出时会回到0重新表示,当一个数据包传输出现问题,服务器一直未收到,而客户端重传后收到了,在处理一些响应后,服务器又收到了之前传输出现问题的包,这时可能出现客户端当前所发数据的序列号回绕且与出现问题的包序列号一致,这时服务器就不能区分哪个是当前需要的数据,加上时间戳就能解决这一问题)
  5. 超时重传时间(RTO)计算:经典算法 SRTT = (x* SRTT) + (1 - x) * RTT (RTT Round-Trip Time 往返时延 , SRTT Smoothed Round-Trip Time 平滑往返时延 , 计算当前的SRTT与上一次的往返时延和上一次的平滑往返时延有关,x是平滑因子 建议值为0.8 ~ 0.9 , x越接近1与上一次的RTT关系越小 )
  6. TCP的流量控制:TCP数据包的发送方和接收方分别有 发送缓冲区 和 接收缓冲区 在这里插入图片描述
    当接收方的接收缓冲区满时发送方就不能再发送数据了,流量控制就时同过接收方的接收缓冲区大小控制发送端的发送。在发送方发送数据后,接收方回复ack时会携带上接收缓冲区的空闲大小。
    在这里插入图片描述
    在这里插入图片描述
    已发送的数据待被确认后蓝色部分和绿色部分就会向右移动,这就是TCP的滑动窗口。
  7. keep-alive:当客户端和服务端三次握手建立连接后,如果客户端断网或故障宕机并不会终止两者之间的连接,这时服务器并不知道下一个数据包永远不会到来,TCP设计者考虑到检测长时间死连接的需求,设计了keep-alive机制,通过定时发送数据包来探测对方是否存活,默认需要7200秒没有数据包交互才发送探测(keep-alive所需时间太长,一般很少使用,多是在应用层设计心跳机制)
  8. 怎么确定收到的数据包是按照传输层的那种协议传输的(TCP或UDP):按照数据包的IP报文中协议位的标识可以看出是哪种传输层协议,ICMP为1、TCP为6、UDP为17;
  9. telnet:可以用telnet + 域名/IP + 端口号 命令来查看对方端口是否可连接
  10. netstat:在这里插入图片描述
  11. tcpdump:tcpdump是命令行式的网络抓包工具,一般用来抓TCP的包。(windows上是windump)
  12. wireshark:windows上的网络抓包工具。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值