Linux网络——传输层

在我们传输层的下面就是运输层,传输层是整个网络体系结构中最重要的一层之一,因为传输层为数据的传输提供服务,这也是网络最基本的要求,数据的共享就需要数据的传输。当然本层设计的内容复杂且逻辑性强,博文将尽量以通俗易懂的方式传递对知识的个人理解。

目录

端口号

认识端口号

端口号和进程id

端口号的划分

实践

命令

UDP

认识UDP

特点

格式

TCP

认识TCP

特点

格式

连接管理机制

确认应答(ACK)机制

超时重传机制

滑动窗口机制

流量控制机制

拥塞控制机制

延迟应答机制

捎带应答机制

TCP总结

TCP与UDP


端口号

  • 认识端口号

在认识网络阶段,有个概念叫数据包的分用,当数据包来到传输层时。还要继续向上一层继续交付,这个时候,它不知道该向哪个进程交付,于是就有了端口号。端口号用来标识一个进程,用来传输层向上交付数据。

端口号是两个字节十六位的整数,所以最大可以表示位65535,所以最多有65535个端口号。

  • 端口号和进程id

前面说端口号是用来标识一个进程,进程id也是标识一个进程的。为社么不用进程id而要用端口号?

这是因为进程id是动态分配,当一个程序运行起来之后,操作系统为该进程分配一个进程id,如果程序再次运行,进程id就会改变,但是端口号不会,端口号在程序运行前就已经固定,即使程序再怎么重启,端口号也不会改变。这两者的关系,就像网卡上的mac地址和ip地址一样。

例如,我们客户端向服务器发起连接时,会用到IP地址和端口号,如果这里的I端口号是进程号,当服务器重启一次后,客户端第二次连接服务器,就不知道端口号了,总不能每次连接都让给服务器查一下进程号,然后告诉客户端,进程id是多少吧。

  • 端口号的划分

端口号有65535个,但是我们写网络程序时不能随意使用。因为大佬有优先使用权。

0 - 1023:知名端⼝号,HTTP、FTP、SSH等这些广为使⽤的应⽤层协议,他们的端⼝号都是固定的。注意,不是协议分配端口号,而是说如果程序这一层用到了这些协议,写程序时优先绑定这些端口号。当然也可以绑定其他的端口号。

1024-65535:操作系统动态分配和程序员使用,当客户端没有绑定端口号时,操作系统则会动态分配一个。

  • 知名协议

  1. ftp服务器, 使⽤21端⼝

  2. ssh服务器,使用22端口

  3. telnet服务器, 使⽤23端

  4. http服务器, 使⽤80端⼝

  5. https服务器, 使⽤443 端口

虽然这些服务器⼀般使⽤这些端⼝, 但这只是⼀个通⽤的习惯. 并不是说HTTP服务器就不能使⽤其他的端⼝号。

  • 实践

一个进程是否可以绑定多个端口?

可以,端口号是标识进程的,可以有多个端口号。就像一个人可以有多个名字:小名,大名,乳名,曾用名。

一个端口是否可以绑定多个进程?

不可以,如果多个进程用同一个端口号,数据到来时,不知道交付给哪一个进程。还是用上面的例子,如果一个班级有两个人同名,老师抽人回答问题时,叫到这个名字,就不知道谁该站起来。

  • 命令

netstat是⼀个⽤来查看网络状态的重要⼯具.

语法:netstat [选项]

功能:查看⺴络状态

常⽤选项

n 拒绝显⽰别名,能显⽰数字的全部转化成数字

l 仅列出有在 Listen (监听) 的服务状态

p 显⽰建⽴相关链接的程序名

t (tcp)仅显⽰tcp相关选项

u (udp)仅显⽰udp相关选项

a(all)显示所有

在传输层,最重要的两个协议就是UDP和TCP了。坐稳了,要发车了。

  • UDP

  • 认识UDP

UDP 英文名User Datagram Protocol, 中文名叫用户数据报协议。

  • 特点

在官方的定义中,有如下特点:无连接,不可靠,面向数据报。押韵且精辟。下面来解释一下。

  1. 无连接:在UDP中,我们只要知道对端的ip地址和端口号就行了,不用提前建立连接,

  2. 不可靠:UDP只管发送数据,至于收不收得到,那就不知道了,所以不可靠。

  3. 面向数据报:应用层交给传输层多长的报文,UDP原封不动的发送出去。

UDP的传输方式就类似写信。只要知道对方的姓名和地址,填上就行了不会告诉对方“我要给你写信了”(无连接);信件寄送出去后,不期待对方的回信,也不管收不收得到,反正寄出去了就完事儿了(不可靠);你给我多长一封信,就只管信封里塞,不分成多次,原封不多的寄送出去(面向数据报)。

当然UDP还不止这么不靠谱,再来看看UDP的缓冲区,UDP在发送数据报的时候,会调用sendto系统调用接口,直接交给内核,由内核交给网络层完成后面的传输,UDP的缓冲区主要是接收缓冲区,缓冲区接收到数据报不能保证和发送数据报的顺序一样,而且如果缓冲区满了,就不接收了,后面来的数据报,就丢掉,让它们随风而去。。。

  • 格式

16位端口号:这个就不解释了,就是端口号,最大也就是65535

16位数据报长度:这个是整个数据报(UDP⾸部+UDP数据)的最⼤⻓度;

16位校验和:如果校验和出错, 就会直接丢弃

UDP的校验和需要计算UDP首部加数据荷载部分,但也需要加上UDP伪首部。伪首部+UDP首部+数据一起计算校验和。伪首部是一个虚拟的数据结构,其中的信息是从数据报所在IP分组头的分组头中提取的,既不向下传送也不向上递交,而仅仅是为计算校验和。

UDP检验和的计算方法是:

按每16位求和得出一个32位的数; 如果这个32位的数,高16位不为0,则高16位加低16位再得到一个32位的数; 重复第2步直到高16位为0,将低16位取反,得到校验和。

注意:

  1. UDP协议⾸部中有⼀个16位的最⼤⻓度。也就是说⼀个UDP能传输的数据最⼤⻓度是64K字节。然⽽64K字节在当今的互联网环境下,是⼀个⾮常⼩的数字。如果我们需要传输的数据超过64K字节,就需要在应⽤层⼿动的分包, 多次发送, 并在接收端⼿动拼装;

  2. 发多少,收多少。如果发送端调用sendto发送100字节,接收端就要用resvfrom接收100字节,不能循环接收,就是说每次接收10字节,循环十次等这样的操作。

TCP

  • 认识TCP

TCP英文名Transmission Control Protocol ,中文名叫传输控制协议。人如其名,要对数据的传输进行一个详细的控制。它是网络协议中的大BOSS。下面来攻克这个大BOOS。

  • 特点

  1. 有连接

  2. 可靠传输

  3. 面向字节流

这三个特点概念对比UDP的三个特点就不难理解了。有连接,就像打电话,我们都会 “ 喂~ ” ,看对方听不听得见,对方则会回复 ”听得见,你说~“,这就是建立连接的过程。这个BOSS最主要的技能便是,可靠传输。我们知道,在网络中,数据的传输是不会可靠的,毕竟丢包的问题很常见,但是可靠传输这便是逆天而行的感觉,所以实现起来非常的繁琐。后面一系列的机制都是为让可靠传输。面向字节流就是说,按字节为单位传输,不像UDP那么”老实“。

  • 格式

源/目的端⼝号:标识源/目的进程

32位序号/32位确认号:实现可靠传输

4位TCP报头⻓度:这里的单位是4字节,所以最大的4位是15,故TCP头部最⼤⻓度是15 * 4 = 60字节。注意:UDP的头部长度是固定的8字节,而TCP是可变的,因为有选项这个位置,具体干嘛的,后面说。

6位标志位:

  1. URG: 紧急指针是否有效

  2. ACK:确认号是否有效

  3. PSH:提⽰接收端应⽤程序⽴刻从TCP缓冲区把数据读⾛

  4. RST:对⽅要求重新建⽴连接; 我们把携带RST标识的称为复位报⽂段

  5. SYN:请求建⽴连接; 我们把携带SYN标识的称为同步报⽂段

  6. FIN:通知对⽅, 本端要关闭了, 我们称携带FIN标识的为结束报文段

16位窗⼝⼤⼩:实现可靠传输

16位校验和:发送端填充, CRC校验,接收端校验不通过,则认为数据有问题,此处的检验和不光包含TCP

⾸部, 也包含TCP数据部分

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

40字节头部选项:后面说

上面的大部分属性都是为了实现可靠传输,下面就是TCP为了它的三个特性,实现的各种机制。由于机制非常巧妙,一环扣一环,但是不好理解,所以会有很多例子帮助理解。

  • 连接管理机制

首先TCP的第一个特点便是有连接,TCP为了实现连接管理,便有了大名鼎鼎的三次握手,四次挥手。下面看是怎么一回事。首先讲个例子来说明三次握手。

我们知道男女关系的建立,是两情相悦的,所以有下面的情况。

我们把收到称为应答,即ACK,把表白称为连接请求,SYN。为什么这里是四次握手?其实三次握手是因为把第二次握手和第三次握手合并了,即就称为了ACK+SYN。由于ACK只是一个bit位,所以可以直接上发送的SYN带上,提高连接的效率。所以就成了下面的图。

上面的漫画,纯属虚构。看完漫画,来说一下实际上服务器和客户端怎么连接。

下面来看一下四次挥手是怎么回事。

对于细节部分,在超时重传部分进行探讨。大致流程如上所述。

  • 确认应答(ACK)机制

根据上面的例子,就很容易理解,确认应答了,但是不仅仅是应答。TCP将每个字节的数据都进⾏了编号,即为序列号。还记得上面TCP格式中的32位序号和32位确认序号吗?就是用在这儿的。

每个ACK确认应答,就会告诉我已经收到了,下一个应该是啥。这个机制在后面还有很重要的作用。

  • 超时重传机制

通过前面的一系列机制,会带来一定量的可靠性,但是任然存在以下情况,举个例子:

于是对应客户端和服务器,就会是:

  1. 客户端发送给服务器的数据丢了
  2. 服务器给客户端的确认应答丢了

针对情况1,如果在一段时间内,客户端没有收到服务器发来的ACK,那么客户端会重新给服务器发送这个数据。

针对情况2,服务器回复的ACK丢了,客户端也会认为数据没到,则又会发送数据,但是服务器已经收到了,这就会造成数据重复。于是上一个机制确认应答中有序号这一功能,便帮助服务器去重,因为序号相同数据,服务器会自动舍弃。

因此超时的时间的确定很重要,不能太长,太长会影响传输效率,也不能太短,太短则会重复的给服务器发送数据。

TCP为了保证⽆论在任何环境下都能⽐较⾼性能的通信因此会动态计算这个最⼤超时时间。

于是在各大操作系统中, 均以以500ms为⼀个单位进⾏控制, 每次判定超时重发的超时时间都是500ms的整数倍,或者说是2的幂次方倍。例如:

重发⼀次之后,仍然得不到应答,等待 2*500ms 后再进⾏重传,之后如果仍然得不到应答,等待4*500ms 进⾏重传。依次类推,以2的指数形式递增。累计到⼀定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接。

  • 滑动窗口机制

在上面的机制中,每发送一个数据,对端都会发送一个ACK确认收到了,而且如果丢失了则会引发重传机制。但是这又会引起一个缺点就是性能较差,也就是说传输得太慢了。那么一个一个传的太慢,干脆一次传多条数据。这样你发送数据的时候,我就能给你发送确认应答,你就不用等我的ACK之后再发送数据,节省了一部分时间。

如图,假设窗口大小是400字节。

  1. 这个滑动窗⼝,其实是操作系统开辟的一个缓冲区,在发送端这就是发送缓冲区,用来来记录当前还有哪些数据没有应答,只有确认应答过的数据才能从缓冲区删掉,删掉之后才会继续填充已经发送的数据。
  2. 在接收端还有一个接收缓冲区,当接收缓冲区的数据被拿走之后,才能将接收到的数据删掉
  3. 窗口的大小就是不用等待ACK,能发送最大数据的最大值,目前是400字节。
  4. 窗口越大,则网络的吞吐率越高。

对于多条发送,多条接收的机制,会有下面的问题。

  1. 某一条ACK丢失
  2. 某一条数据丢失

对于问题1,如果某一条ACK丢失,只要后续的ACK到达,TCP默认前面的也到达了。

对于问题2,如果某一条数据丢失,这个时候,接收端会一直发送丢失数据的ACK,如果连发三次,则发送端会再发一次该序号的数据。

  • 流量控制机制

在滑动窗口的机制下,接收端处理数据的速度是有限的,所以如果发送端发送数据太快,就会导致接收端的缓冲区被占满,然后就会丢包,然后就会重发等一系列连锁反应。

因此TCP根据接收端处理数据的能力来控制发送数据的快慢, 这个机制就叫做流量控制。

  1. 接收端将自己可以接收的数据的大小放在TCP首部的窗口大小中。通过ACK通知发送端。又一个头部字段出现。
  2. 接收端⼀旦发现⾃⼰的缓冲区快满了,就会将窗⼝⼤⼩设置成⼀个更⼩的值通知给发送端;
  3. 发送端接受到这个窗⼝之后, 就会减慢⾃⼰的发送速度;
  4. 如果接收端缓冲区满了,就会将窗⼝置为0;这时发送⽅不再发送数据,但是需要定期发送⼀个窗⼝。
  5. 探测数据段, 使接收端把窗⼝⼤⼩告诉发送端

(注意:虽然头部信息中的窗口大小是16位,也就是65535字节,其实,头部中还有一个选项,选项中有一个扩大因子M,实际窗口大小是头部中的大小左移M位的值。)

  • 拥塞控制机制

在这之前,感觉TCP的可靠传输已经基本成型了,是的。后面就是优化了。因为在前面还有一些值得优化的地方。比如:

TCP引⼊慢启动机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多⼤的速度传输数据。如果当前网络的状态不是很好,但我们不知道,还是一下子就传很大的数据,这样会加重拥堵。

  1. 因此引⼊⼀个概念程为拥塞窗口。
  2. 发送开始的时候, 定义拥塞窗⼝⼤⼩为1,先发送一个字节的数据。
  3. 每次收到⼀个ACK应答,拥塞窗⼝加1。
  4. 每次发送数据包的时候,将拥塞窗⼝和接收端主机反馈的窗⼝⼤⼩做⽐较,取较⼩的值作为实际发送的窗⼝。

像上⾯这样的拥塞窗⼝增⻓速度,是指数级别的。"慢启动" 只是指初使时慢,但是增⻓速度⾮常快。开始拥塞窗口为1,然后收到发送的第一个的ACK后,拥塞窗口加一,这个时候拥塞窗口就是2。然后就会发两个报文出去,然后就会收到两个ACK,现在就会又加二,拥塞窗口就会变成四,因此拥塞窗口的变化就是:1、2、4、8、16……。也就是指数型增长。

因此为了不让拥塞窗口增加的太快,因此增加一个标记,也可以叫做水位,也可以叫做阈值。反正就是起一个标记的作用。当窗口大小增加都这个阈值时,就变成线性增长。然后,在后面如果遇到了网络阻塞,那则TCP又开始慢启动,循环这个拥塞控制机制,但是这个阈值会变成遇到网络拥塞时拥塞窗口大小的一半。

什么时候是网络拥塞呢?当少量丢包时就触发重传机制,大量的丢包就触发拥塞控制机制。

现在用一个例子来解释这个拥塞控制机制。

  一对情侣一开始确定关系时,都很羞涩,感情升温比较慢(慢开始),但是随着时间的推移,进入了热恋期,感情呈指数增长(指数增长)。慢慢的新鲜感过去之后,有归于平淡,感情呈线性增长(阈值之后)。突然有一天,所有的委屈,不公平,忍耐爆发了,大吵了一架,互相都不理谁,于是感情归于0(网络拥塞)。时间慢慢过去,两个人突然觉得自己做的是不太对,于是两个人互相认错,慢慢的又开始坠入爱河(慢开始),因为吵了一架,再一次深入了解了自己和对方,爱的更加深沉(指数增长)。但是这次的新鲜感并没有一开始持久(拥塞窗口减小),于是感情有归于平淡(阈值之后),有一天,又因为一件小事,吵了一架,又开始了循环网络拥塞),知道没有了慢开始,没有了指数增长的感情,成了线性增长……

所以拥塞窗口机制告诉了我们,爱情并不是风华雪月,而是柴米油盐。

  • 延迟应答机制

这个就比较简单了,就是说,当接收端进行ACK应答的时候,因为会带上窗口的大小,所以干脆等一会在回答,等接收缓冲区的数据被取走一部分后,再回答。这个时候窗口也变大了。

窗口越大,传输效率就越高。

  • 捎带应答机制

我们知道,接收端不仅仅只是发送给一个ACK,有时候也要发送一些,发送端要的资源。例如客户端发起HTTP请求,要一个HTML网页时,可以让ACK做一个顺丰车,毕竟ACK只是一个bit位。

  • TCP总结

到这儿,基本上就把TCP这个boss解决了,本章博文用时10个小时。大部分都是TCP,可见TCP是多么复杂。复杂的就是它的可靠性。

有连接:

  1. 连接管理机制

可靠性:

  1. 校验和
  2. 序列号(按序到达)
  3. 确认应答
  4. 超时重发
  5. 连接管理
  6. 流量控制
  7. 拥塞控制

性能优化:

  1. 滑动窗⼝
  2. 快速重传
  3. 延迟应答
  4. 捎带应答

TCP与UDP

TCP用于可靠传输,例如文件传输等

UDP用于高速传输和实时性较高,例如游戏。

©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页