计算机网络——传输层

传输层概述

传输层:只有主机才有的层次,为应用层提供通信服务,使用网络层的服务。

传输层的功能:

  1. 传输层提供进程和进程之间的逻辑通信
  2. 复用和分用
    复用:应用层所有的应用进程都可以通过传输层再传输到网络层。
    分用:传输层从网络层收到数据后交付指明的应用进程。
  3. 对收到的报文进行差错检测

传输层的寻址与端口:
逻辑端口/软件端口端口是传输层的SAP,标识主机中的应用进程。
端口号只有本地意义,在因特网中不同计算机的相同端口是没有联系的。
端口号长度为16bit,能表示65536个不同的端口号。
在这里插入图片描述
在网络中采用发送方和接收方的套接字组合来识别端点,套接字唯一标识了网络中的一个主机和它上面的一个进程。
在这里插入图片描述

TCP协议

面向连接的传输控制协议
传送数据之前必须建立连接,数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务,因此不可避免增加了许多开销:确认、流量控制、计时器及连接管理等。

可靠,面向连接,时延大,适用于大文件。

特点:
在这里插入图片描述

TCP报文段首部格式

在这里插入图片描述
序号:在一个TCP连接中传送的字节流中的每一个字节都按顺序编号,本字段表示本报文段所发送数据的第一个字节的序号
确认号:期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N,则证明到序号N-1为止的所有数据都已正确收到。
数据偏移(首部长度) : TCP报文段的数据起始处距离TCP报文段的起始处有多远,即TCP首部长度,以4B位单位,即1个数值是4B。

紧急位URG: URG=1时, 标明此报文段中有紧急数据,是高优先级的数据,应尽快传送,不用在缓存里排队,配合紧急指针字段使用。
确认位ACK: ACK=1时确认号有效, 在连接建立后所有传送的报文段都必须把ACK置为1。
推送位PSH: PSH=1时, 接收方尽快交付接收应用进程,不再等到缓存填满再向上交付
复位RST: RST=1时, 表明TCP连接中出现严重差错,必须释放连接,然后再重新建立传输链接。
同步位SYN: SYN=1时,表明是一个连接请求/连接接受报文。
终止位FIN: FIN=1时, 表明此报文段发送方数据已发完,要求释放连接。

窗口:指的是发送本报文段的一方的接收窗口,即现在允许对方发送的数据量。
检验和:检验首部+数据,检验时要加上12B伪首部,第四个字段为6。
紧急指针: URG=1时才有意义,指出本报文段中紧急数据的字节数。
选项:最大报文段长度MSS、窗口扩大、时间戳、选择确认…

TCP连接管理

在这里插入图片描述
TCP连接的建立采用客户服务器方式,主动发起连接建立的应用进程叫做客户,而被动等待连接建,立的应用进程叫服务器。

三次握手:

假设运行在一台主机(客户)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接,客户应用
进程首先通知客户TCP,他想建立一个与服务器上某个进程之间的连接,客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接:
在这里插入图片描述
在第二次和第三次握手中,服务器端和客户端会为TCP连接分配缓存和变量,有可能导致SYN洪范攻击:

SYN洪泛攻击发生在OSI第四层,这种方式利用TCP协议的特性,就是三次握手。攻击者发送TCP SYN, SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。(解决方法:设置SYN cookie)

四次握手

参与一条TCP连接的两个进程中的任何-一个都能终止该连接,连接结束后,主机中的“资源" (缓存和变量) 将被释放。
在这里插入图片描述
为什么要等待2MSL:(MSL:报文段最长寿命)
如果第四次握手没有到达服务器端,服务器端就会重新第三次握手,客户端就会在2MSL时间内收到服务器端的第三次握手,然后执行第四次握手。
如果不等待2MSL,服务器端一旦没有收到客户端的第四次握手信息,就会不停地向客户端执行第三次握手,服务器端就无法正常释放连接。

可靠传输

网络层:提供尽最大努力交付,不可靠传输
传输层:使用TCP实现可靠传输

可靠:保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。

校验

与UDP校验一样,增加伪首部(见后文)

序号

TCP协议是面向字节流的,发送时把字节组合在一起,形成一个报文段,报文段大小取决于链路层的MTU(最大传输单元)
在这里插入图片描述
有了序号的机制,就能保证数据有序地提交给应用层,并且衍生出确认机制和重传机制。

确认

发送方发送一个报文段,直到接收方确认已经完整正确地收到,才能将该报文段从发送方地TCP缓存中删除。
两种实现形式

  1. 累计确认
  2. 稍待确认

确认报文段首部,确认号字段是期待收到的下一个字节的序号
TCP默认使用累计确认(发送方发送了【123】【45】两个报文段,但是接收方只接收到了【45】报文段,那么返回的确认报文首部的确认号字段还是1)

重传

确认重传不分家,TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。(超时重传)
TCP采用自适应算法,动态改变重传时间RTTs ( 加权平均往返时间)。
但是超时重传还是等太久了

于是就有了冗余确认的机制(快重传技术)
发送方已发送1,2,3,4,5报文段
接收方收到1,返回给1的确认(确认号为2的第一个字节)
接收方收到3,仍返回给1的确认(确认号为2的第一一个字节)
接收方收到4,仍返回给1的确认(确认号为2的第一个字节)
接收方收到5,仍返回给1的确认(确认号为2的第一个字节)
发送方收到3个对于报文段1的冗余ACK→认为2报文段丢失, 重传2号报文段

流量控制

让发送方慢点,要让接收方来得及接收
TCP利用滑动窗口机制实现流量控制。
在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小,即接收窗口rwnd(接收方设置确认报文段的窗口字段来将rwnd通知给发送方),发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。
在这里插入图片描述
TCP为每一个连接设有一个持续计时器,只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段。接收方收到探测报文段时给出现在的窗口值。若窗口仍然是0,那么发送方就重新设置持续计时器。

拥塞控制

出现拥塞的条件:
对资源需求的总和>可用资源
网络中有许多资源同时呈现供应不足 -> 网络性能变坏 -> 网络吞吐量将随输入负荷增大而下降

拥塞控制:
防止过多的数据注入到网络中。全局性

在这里插入图片描述

慢开始&拥塞避免

在这里插入图片描述
一个传输轮次:
发送了一批报文段并收到它们的确认的时间。一个往返时延RTT。开始发送一批拥塞窗口内的报文段到开始发送下一批拥塞窗口内的报文段的时间。

ssthresh:慢开始门限

快重传&快恢复

在这里插入图片描述

UDP协议

无连接的用户数据报协议
传送数据之前不需要建立连接,收到UDP报文后也不需要给出任何确认。

不可靠,无连接,时延小,适用于小文件。

UDP只在IP数据报服务之上增加了很少功能,即复用分用和差错检测功能。

UDP的主要特点:

  1. UDP是无连接的,减少开销和发送数据之前的时延。
  2. UDP使用最大努力交付,即不保证可靠交付。
  3. UDP是面向报文的,适合一次性传输少量数据的网络应用。应用层给UDP多长的报文,UDP就照样发送,即一次发一个完整报文
    应用层给UDP多长的报文,UDP就照样发送,即一次发一个完整报文
  4. UDP无拥塞控制,适合很多实时应用。
  5. UDP首部开销小,8B, TCP20B。
    在这里插入图片描述

UDP如何校验:
在这里插入图片描述
在这里插入图片描述

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

取个名字真难啊啊

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值