网络协议之TCP

TCP协议

  • TCP协议段格式

在这里插入图片描述

  • 4位TCP报头长度:4位表示的最大10进制数为15,15*32/8= 60字节 所以报头最大长度为60字节

  • 6位标志位:

    1. URG:紧急指针是否有效
    2. ACK:确认号是否有效
    3. PSH:提示接受端应用程序立即从TCP缓存区把数据读走
    4. RST:对方要求重新建立连接;携带RST标识的报文段称为复位报文段
    5. SYN:请求建立连接;携带SYN标识的称为同步报文段
    6. FIN:通知对方本端关闭,携带FIN为结束报文段
  • 16位校验和:发送端填充,CRC校验,接收端校验不通过,则认为数据有问题,校验和不光包含TCP首部,也包含TCP数据部分

  • 16位紧急指针:标识哪部分数据是紧急数据

  • TCP三次握手四次挥手

在这里插入图片描述

  • 三次握手

    1. 调用socket,创建连接套接字
    2. 调用connect,向服务器发起连接请求
    3. connect发出SYN段并阻塞等待服务器应答(第一次握手)
    4. 服务端收到客户端的SYN后,会应答一个SYN-ACk段表示同意建立连接 (第二次握手)
    5. 客户端收到SYN-ACK后会从connect返回,同时应答一个ACK段
  • 四次挥手

    1. 客户端调用close,发出FIN段(第一次挥手)
    2. 服务端收到FIN段,会应答一个ACK,同时服务端read会返回0 (第二次挥手)
    3. read返回0后,服务端知道客户端关闭了连接,所以也会close关闭连接,此时发出一个FIN段(第三次挥手)
    4. 客户端收到FIN段,再返回一个ACK给服务端
  • 问题:

    1. 为啥需要第三次握手:

      需要第三次握手的原因是如果A向B发送连接请求报文段,由于网络原因滞留了,直到连接释放后才到达B,这个报文段是一个失效的请求报文段,B误以为收到了新的连接请求,于是就向A发出了确认报文段,同意建立连接,但是A并没有发出建立连接的请求,因此不会理会B的确认,但B认为新的连接已经建立了,就会白白创建connfd浪费资源

    2. 为啥需要四次挥手

      当服务端收到客户端发来的FIN段时,很可能不会立即调用close关闭socket,所以只能先发送一个ACK确认服务端已经收到,然后等服务端所有的报文全部发完,再调用close关闭socket并发送FIN段

    3. 为什么TIME_WAIT状态需要2MSL才能回到CLOSED状态

      客户端接收到服务端发送的FIN端后,会向服务端发送一个ACK段,如果发送的这个ACK段在网络传输的过程中丢失了,那么服务端没有收到ACK段,就会继续重复发送FIN段,所以客户端不能立即关闭,必须确认服务端接收到了ACK

    4. 如果建立了连接,客户端故障了

      TCP设有保活计时器,服务端每收到一次客户端请求都会重置这个计时器,时间通常是两小时,若两个小时还没收到客户端任何数据,服务端就会发送一个探测报文,以后每隔75秒发送一次,若连发10次没反应就关闭连接

  • 确认应答机制(ack)

    TCP是面向字节流传输,TCP将每个字节的数据都编号,即序列号,当发送数据时都会携带seq,如seq=1,同时接收端会有一个ack带有确认序号,表明收到了那些数据,下次从哪发送如:ack=1001;

  • 超时重传

    1. 主机A发送数据给主机B,由于网络状况,数据无法到达主机B,如果主机A在一段时间内没有收到B发来的确认应答,就会重发
    2. 主机A没有收到主机B的ACK,也可能是ACK丢了,因此主机B会收到很多重复数据,所以TCP会通过序列号来去重

    TCP会动态计算超时时间,超时以500ms为一个单位,每次判定超时重发的时间是500ms的整数倍

  • 滑动窗口

    1. 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。
    2. 收到第一个ACK,滑动窗口向后移
    3. 操作系统内核为了维护这个滑动窗口,需要开辟发送缓存区来记录当前还有哪些数据没有应答,确认应答的数据,才能从缓冲区删掉
    4. 窗口越大,则网络的吞吐量就越高

    丢包重传:

    1. 数据包递达,ACK丢了

      不影响,可以通过后续的ACK确认

    2. 数据包丢了

      当一段报文段丢失后, 发送端会一直收到服务端应答的丢失ACK的确认序号

      如果发送端连续三次收到同一序号,就会将丢失的数据包重发

      当接收端接收到正确的ACK后,再次返回的ACK应是丢失ACK+6 *(序列大小),其实之前发送的都已经收到了,被放在内核的接收缓冲区

  • 流量控制

    接收端处理数据的速度是有限的,当发送端发送数据过快导致接收区的缓冲区被装满,这个时候发送端继续发送就会发生丢包,继而引起重传等一系列连锁反应,因此通过窗口大小来控制发送端的发送速度,这种机制就叫做流量控制

    1. 接收端将自己可以接受的缓冲区大小 放入TCP首部的16位窗口大小字段,通过ACK段通知发送端
    2. 窗口大小越大,说明网络的吞吐量越高
    3. 接收端一旦发现缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端
    4. 发送端接收到这个窗口大小后,就会减缓发送速度
    5. 如果接收端缓冲区满了,就会将窗口置为0,这时发送端不会发送数据,但是要定期发送窗口探测数据,以便实时检测缓存区是否有空余
  • 拥塞控制

    在网络情况不明的情况下,贸然发送大量数据,将会是其更加拥堵, TCP引入慢启动,先发送少量的数据测试传输速度,再确定用多大速度传输数据

    1. 发送开始时定义拥塞窗口大小为1
    2. 每次收到一个ACK应答,拥塞窗口加1
    3. 每次发送数据包时 将拥塞窗口和接收端反馈的窗口大小做对比,取较小的值作为实际发送的窗口
    4. 当拥塞窗口大小小于阈值,将指数增长,否则线性增长
  • 延迟应答

    如果接收数据的主机立即返回ACK应答,返回的窗口可能较小,所以需要延迟,是窗口大小变大

    数量限制: 每隔N个包应答一次

    时间限制: 超过最大延迟时间就应答一次

  • 捎带应答

    客户端向服务端发送数据后,服务端也发送数据时,ACK就可以和数据包一起回传给客户端

  • 面向字节流

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

发出去

  • 接收数据时,数据也是从网卡驱动程序到达内核的接收缓冲区
  • 然后应用程序可以调用read从接收缓冲区拿数据
  • 另一方,TCP的连接,既有发送缓存区,又有接收缓冲区,那么对于这一个连接,既可以读数据,也可以写数据
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值