【计算机网络】——详解传输层TCP/UDP

1.传输层:

  功能:负责数据能够从发送端传输连接端。

       (1) 端口号:找到应用程序;

       (2) 端口号取值范围:0-65535;

       (3) 分类:知名端口号:0-1023   如FTP——21;SSH——22;Telnet——23;Http——80;Https——443;DNS——53;

                           操作系统动态分配的端口号:1024-6535    如客户端程序的端口号;

(1)一个进程(程序)是否可以绑定多个端口号?

         可以。

(2)一个端口号是否可以被多个程序使用吗?

         不可以。

2.UDP协议

 (1)UDP协议端格式  ——8个字节:

16位源端口号16位目标端口号
16位UDP长度 16位UDP校验和
                                                   数据

(2)校验和:用来确定数据在传输的过程中是否被篡改,即判断数据的正确性;

如何进行校验?

如采用MD5进行校验——>将原始数据和MD5进行计算的值——>将其值存入到16位的校验和当中;

接收端接收到内容之后,按照通过的规则加密数据得到一个校验和,用这个计算出来的校验和与UDP头中的

位校验和对比,如果相等,则此数据是正确的。

 (3)16位UDP长度 = UDP头部长度(8个字节) + 数据长度;

 (4) UDP一个包的最大理论长度 = 2^16  即 65536/1024= 64KB;

如果UDP编程的时候的数据大小大于64KB,如何解决?

方案1:在应用层进行数据报的拆分和组合;

方案2:大于64KB,不进行处理,可以交给下层(网络层:TCP/IP协议)去处理,它会在网络层进行分包和组包。——  一般不采用。——  不保证质量,有丢包风险。

(4)UDP的特点:

  • 无连接——知道接收端的IP和端口号就可直接进行传输,不需要建立连接;
  • 不可靠——没有确认机制,没有重传机制;如网络故障引起的无法发送到接收端,不会给应用层返回任何错误信息;
  • 面向数据报:不能灵活的控制读写数据的次数和数量;应用层交给UDP的数据报,不会对其进行拆分和合并等。
  • UDP的缓冲区——没有发送缓冲区,只有接收缓冲区;

(5)UDP 的使用长南京:DNS(域名解析服务)【域名和IP的映射】。

(6)UDP的socket既能读取,也能写入,即全双工。

全双工指发送端或者接收端既可以发送消息,也可以接收消息UDP和TCP
 半双工发送端只能发送消息,不能接收消息;接收端只能接收消息,不能发送消息。 

3.TCP协议

(1)Transmisssion Control Protocol 传输控制协议,即对数据的传输进行控制;

(2)协议段格式

  • 16位源端口号——发送程序
  • 16位目标端口号——接收程序
  • 32位序号——消息的身份标识(TCP对每个字节的数据都进行了编号,即序列号)
  • 32位确认号
  • 4位TCP报头长度——标识该TCP头部有多少个32为bit(有多少个4字节);
  • 6位标志位

URG

当是1,表示紧急指针

ACK

是否确认应答消息

PSH

是否自己从缓冲区取走数据

RST

复位标识

SYN

同步序列号标识(TCP连接时使用)

FIN

结束序列号(TCP进行断开连接时使用)

  • 16位窗口大小——记录的是如果16位的滑动窗口大小                        
  • 16位校验和——发送端填充,CRC校验和
  • 16位紧急指针——标识哪部分数据是紧急数据
  • 40字节头部选项
  • 数据

(3)TCP的8大特性——保证稳定性,高效能

8大特性作用可能问题以及缺点
确认应答机制(ACK)

保障TCP稳定的核心机制

接收方拿到消息之后,给予应答。

TCP将每个字节的数据都进行了编号,即为序列号,每一个ACK都带有对应的确认序列号。

(1)发送消息丢失;(2)ACK丢失
超时重传机制

内核:自动进行消息去重;Linux中,默认时间500ms。

策略:(1)发送不会以固定的频率发送;采取的是悲观策略;TCP采取指数形式递增的频率来发送消息;

           (2)如果超过一定的重试次数,消息还未得到应答(TCP认为网络或者对端主机出现异常,强制关闭连接),                      则停止发送消息

一发一收的应答形式,当数据往返的时间较长的时候,性能差;
连接管理机制

正常情况,TCP会经过:3次握手(3次通讯syn ——>( syn + ack) ——> ack)建立连接,——为了验证收发两端的收发机制(即双工能力);

4次挥手(4次通讯fin ——>(ack——>fin)——>ack)断开连接;——为了确保发送端和接收端能正常关闭;

延迟应答 + 捎带应答 ——>使得3次挥手有了可能(取决于接收缓冲区中是否有任务)。

性能低
滑动窗口

一次发送多条数据,可以提高传输性能;

窗口大小指的是无需等待确认应答而可以继续发送数据的的最大值,

操作系统内核为了维护滑动窗口,需要开辟“发送缓冲区”来记录当前还有安歇数据没有应答;只有确认应答过的数据,才能从缓冲区删掉。

(1)数据报直接丢了;——当前前面丢失的数据正常补齐之后,返回的是ACK的最大值,此机制称为“快重传”

(2)数据报已经抵达,ACK丢失了;——可以通过后续ACK进行确认。

流量控制

TCP支持根据接收端的处理能力,来决定发送端的发送速度,此机制即流量控制(Flow Control);

本质:根据接收缓冲区的大小的结果为导向进行数据的传递;

如果在刚开始就发送大量的数据,也可引发问题。
拥塞控制

TCP引入慢启动机制,先发送少量的数据,根据当前时间的网络来动态在调整收发的频率。

本质:以当前网络环境的拥塞程度为导向。

 
延迟应答

策略:(1)每隔一段时间(固定时间取200ms)延迟应答一次——一定程度上加快发送消息的速度;

           (2)每隔N(一般取2)个包延迟应答一次;

注意:延迟应答的时间(200ms)一定要小于超时重传的时间(Linux:500ms)
捎带应答针对延迟应答的性能优化基于延迟应答的性能(“一收一发”)提升

(4)面向数据流——没有明确边界,可能会导致粘包和半包问题。

         粘包和半包都是用来指得到的数据不是预期的数据。

         粘包和半包问题解决:

               方案1:在服务器端使用BufferedReader(使用readLine()方法) 、BufferedWriter;客户端加入结束标识符\n——以进行流的分割;

               方案2:每次发送固定大小的数据(以空格进行填充——trim());

(5)TCP异常处理情况:

  •  可挽救异常:电脑重启或者结束进程的时候,它会发送FIN请求,和正常关闭TCP没有什么区别。
  •  不可挽救异常:电脑断电/网线中断:TCP内置了保活定时器,会定时检测对方是否在线,如果检测的结果是没有任何响应,说明已经掉线。

4.TCP既可保证稳定性,又可以提高性能

TCP保证稳定性(1)确认应答机制;(2)超时重传机制;(3)连接管理机制;(4)流量控制;(5)拥塞控制
保证性能(1)滑动窗口;(2)延时应答;(3)捎带应答;

问题1:

(1)为什么需要3次握手?

只有经过3次握手,才可以完整的证明客户端和服务器端具有的发送和接收能力(全双工);

(2)3次挥手是否可以?

有可能可以。取决于接收缓冲区是否有任务。

如果没有待结束的任务两次挥手可以合并;——即捎带应答。

对应到程序,如果接收缓冲区没有数据了。则可以直接关闭连接。

问题2:

拥塞控制的执行原理:—— 慢启动机制

(1)刚开始先发送1个包,如果可以正常接收就会以指数形式增加发送的数据报数量,一直增加到流量控制的最大值之后,就会按照线性方式增长;

(2)当TCP开始启动的时候,慢启动阈值等于窗口最大值;

(3)在每次超时重发的时候,慢启动阈值会变成原来的一半,同时拥塞窗口置回1;

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值