网络通信----传输层:负责端与端之间的数据传输----TCP/UDP

传输层:负责端与端之间的数据传输----TCP/UDP


       一、  UDP:
          UDP协议:无连接,不可靠,面向数据报(不会产生粘包问题)
          UDP协议报头:源端口,目的端口,数据包长度,校验和
          
          校验和:二进制反码求和
          
          面向数据报不会产生粘包问题:因为UDP数据包中自定义了数据包的长度
          udp数据包最大长度64K(包含报头);
          若用户sendto发送的数据长度大于64k则会报错:因为udp在传输层不会自动进行数据分段
          
          数据报长度是一个uint16_t类型的数字,这就决定了数据报最大长度64k;数据长度就是64k-8
          意味着如果传输的数据若大于64k,则需要用户在应用层就进行数据分段;
          但是传输层udp并不保证数据的有序到达,因此需要用户在应用层进行包序的管理
          
          udp场景:实时性较高
          udp协议内部实现了广播功能--udp广播
       二、TCP: 
          TCP协议:面向连接,可靠传输,面向字节流
           TCP连接管理:
              TIM_WAIT:假如没有TIME_WAIT状态,主动关闭方直接进入CLOSED,如果立即重启客户端
           使用相同的端口,在最后一次ACK关闭失效以后,服务端重新发送FIN请求,就会被新启
           动的客户端收到;或者新启动的客户端发起请求的时候,因为服务端正在等待最后一次ACK
                       因此新连接请求发送的SYN就会被认为请求码错误,服务端就会恢复RST重置连接
           因此需要主动关闭方发送最后一次ACK之后进入一个TIME_WAIT状态等待一段时间:2个MSL
           MSL:最大报生存周期
           1.等待这段时间就是为了若接收到重发的FIN请求能够进行最后一次ACK回复
           2.让在网络中延迟的FIN/ACK消失在网络中,不会对后续的连接造成影响
           
           TCP的可靠传输
              确认应答机制/超时重传机制,协议中的序号/确认序号, 校验和 
              
              确认应答机制:超时重传机制-保证数据安全到达
              协议中的序号/确认序号:进行包序管理
              校验和:验证数据的一致性
            tcp为了实现可靠传输,牺牲了部分性能;因此又引入了各种机制来针对不同场景提高传输性能
            
            滑动窗口机制:流量控制
                滑动窗口规定:
                (1)ack确认丢失的情况:每条数据都要进行回复,并且应该按顺序逐条回复,如果没有收到第一条,
            但是都到了第二条,第二条就不能先回复,应该先回复第一条;带来的好处就是,因为第一条ack
            丢失后,如果发送端收到第二条回复,也会认为第一条正常接收,第一条就不需要重传了
            
                (2)数据丢失的情况: 当数据连续发送N条,但是第一条数据丢失,接收端先接收第二条,这
            时候接收端认为第一条数据有可能丢失,因此直接开始向发送端发送第一条的数据重传请求;连续发
            三次(防止网络延迟又接收到数据报);当发送端接收到三条重传请求,则会对这条数据进行重传
            
            滑动窗口
                通信双方通过协议中的窗口字段,来协商能够一次发送的最多的数据,然后连续发送多条数据;
             在socket中使用两个指针维护窗口前沿和后沿
               发送端:发送的起始位置-后沿,前沿就是发送的结束位置;--若窗口后沿数据没有接收ack确认,
            后沿不能移动,数据就不能从缓冲区移除,接收到ack确认后就会让后沿向后移动
               接收端:接收数据的起始位置-后沿,接收的结束位置-前沿;当接收数据的时候若没有接收到
            第一条数据,则后沿不能动,只有接收到数据后,后沿才会向前移动
            
            产生的问题: 滑动窗口机制,通过窗口大小来确定连续发送多条数据;但是一开始通信的时候,因为不
            了解网络状态,有可能造成发的越多,丢的越多,超时重传就越多,降低效率
            滑动窗口机制中的拥塞窗口:定义一个拥塞窗口限制通信起始时候,数据的发送速度,以及一个阈值(窗口大小)
            控制增长上限;在通信中以慢启动,快增长的形式尽力避免因为网络状况不好导致的丢包发生
            
          tcp提高传输性能的机制
            延迟应答机制:尽可能的保持窗口大小,保持网络传输吞吐率
            捎带应答机制:尽量减少不必要的确认应答报文(在发送数据的时候顺便对上一次的请求进行ACK回复)
            
           tcp面向字节流
            传输数据并不关心是什么数据,只管二进制的数据流        
            tcp粘包问题:缓冲区的数据对于tcp来说没有边界;造成数据粘连的问题
            本质问题:数据没有边界
            需要在用户在应用层进行边界管理:
                特殊字符间隔(http协议)
                定长数据
                变长数据(udp中包含数据长度)
            **udp不会产生粘包问题    


          TCP协议字段:
             16位源端口/目的端口;
             32位序号/确认序号;
             4位头部长度;
             6位标志位:(URG/AKC/PSH/RST/SYN/FIN)    
             16位窗口大小;
             16位校验和;
             16位紧急指针;
             40字节的选项数据(MSS)
         TCP的连接断开:
             进程退出,会进行四次挥手断开连接流程
             关机,会进行四次挥手断开连接流程
             网线断开/断点:tcp内部实现保活机制keep—alive,长时间无通信则进行网络探测;
             连续多次进行探测无响应,认为连接断开;外在表现:recv 返回0/send 发生异常--SIGPIPE-导致进程退出
       基于tcp的应用层协议:http/https/ssh/telnet

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值