目录
应用层重点协议
传输层重点协议
1.UDP协议
(一)UDP协议段格式
(二)UDP的特点
无连接
不可靠传输
面向数据报
全双工
缓冲区
大小受限
(三)基于UDP的应用层协议
(四)面试题
2.TCP协议
(一)TCP协议段格式
(二)TCP的特点
有连接
可靠传输
面向字节流
缓冲区
全双工
粘包问题
异常情况
(三)基于TCP应用层协议
编辑网络层重点协议
IP协议
数据链路层重点协议
面试题
我们知道TCP/IP五层(或四层)模型包括:
- 应用层
- 传输层
- 网络层
- 数据链路层
- 物理层
那网络传输是怎样具体展开的呢~
举个例子(发送方“封装”)(接收方要“分用”)
下面我们就来学习各个层的重点协议~~
- 16位UDP长度,表示整个数据报(UDP首部+UDP数据)的最大长度
- 如果校验和出错,就会直接丢弃
知道对方的IP号和端口号就能直接进行传输,不需要建立连接
没有任何安全机制,发送端发送数据报后,如果遇到网络故障该段无法发送过去,UDP协议层也不会给应用层返回任何错误信息
应用层发给UDP多长的报文,UDP原样发送,既不会拆分也不会合并
UDP的socket既能读也能写
UDP只有接收缓冲区,没有发送缓冲区
UDP没有真正意义上的 发送缓冲区。发送的数据会直接交给内核,由内核将数据传给网络层协议 进行后续的传输动作;
UDP具有接收缓冲区,但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一 致;如果缓冲区满了,再到达的UDP数据就会被丢弃;
UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。
当然,也包括你自己写UDP程序时自定义的应用层协议。
1. UDP本身是无连接,不可靠,面向数据报的协议,如果要基于传输层UDP协议,来实现一个可靠传 输,应该如何设计?
2. UDP大小是受限的,如果要基于传输层UDP协议,传输超过64K的数据,应该如何设计?
以上两个问题答案类似,都可以参考TCP的可靠性机制在应用层实现类似的逻辑:
例如:
- 引入序列号,保证数据顺序;
- 引入确认应答,确保对端收到了数据;
- 引入超时重传,如果隔一段时间没有应答,就重发数据;
- ……
在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接
那啥叫断开连接呢?
A和B把自己存储的连接信息(数据结构)删了,连接就是断开了~~
三次握手:
建立连接阶段,主要认识两个状态:
1.LISTEN 服务器的状态
表示服务器已经准备就绪,随时可以跟客户端来建立连接,相当于手机开机,信号良好,随时可以有人来打电话~~
2.ESTABLISHED 客户端和服务器都有
表示连接建立完成,接下来就可以正常通信了,相当于电话拨过去,对方接通了~~
四次挥手:
断开连接阶段,主要认识两个状态:
1.TIME_WAIT
TIME_WAIT表示要保持当前的TCP连接状态不要立即就释放~
为什么不要连接释放呢?
TIME_WAIT如果等待了一段时间后也没收到重传的FIN,此时就认为,最后的一个ACK没丢,于是就彻底的释放连接了~
2.CLOSE_WAIT 出现在被动发起断开连接的一方
建立连接一定是客户端主动发起请求的,断开连接,可能是客户端主动发起,也可能是服务器主动发起~
CLOSE_WAIT表示等待关闭,等待调用close方法关闭socket
有连接和确认应答的区别:
确认应答机制
网络后发先至这个现象是客观存在的,如何解决这个问题呢?
方法很简单,给传输的数据和应答报文,都进行编号就可以了!!!
TCP将每个字节的数据都进行了编号。即为序列号。
每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。
超时重传机制
主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发;
如果一直丢包,主机A会一直重传吗?
答案是不会的~
但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了;
由于主机B返回的确认应答因网络堵塞等原因在传输的途中丢失,没有到达主机A,主机A会等待一段时间,若在特定时间间隔始终未能收到确认应答,主机A会对此数据进行重发,此时,主机B将第二次发送已接收数据的确认应答,由于主机B已经收到过1~1000的数据,当再有重复数据送达时它会放弃~~
滑动窗口机制
刚才我们讨论了确认应答策略,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送 下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候
既然这样一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多 个段的等待时间重叠在一起了)
当批量发送了窗口大小的这些数据之后,发送方就要等待ACK了
那么啥时候继续往下发送呢?发送方不是等待所有的ack到达才继续往下发,而是到了一个ack,就继续往下发一条...
如上图的例子,那么我们等待的ack始终是4条~
那么如果出现了丢包,如何进行重传?这里分两种情况讨论。
情况一、数据包丢了
情况二、ack丢了
这是一种干预发送窗口大小的机制
滑动窗口越大,传输效率越高(一份时间,等待的ack越多)
但是,窗口也不能无限的大~否则会造成以下的问题:
1.完全不等ack,可靠性能否保障画上问号
2.窗口越大,也会消耗大量的系统资源
3.发送速度太快,接收方处理不过来,发了也白发
接收方的处理能力,就是一个很重要的约束依据
发送方发数据的速度,不能超过接收方的处理能力
流量控制要做的工作就是这个,根据接收方的处理能力,协调发送方的发送效率
那如何衡量接收方的处理能力?
其实可以直接看接收方接收缓冲区的剩余大小~
当窗口大小为0,发送方就要暂停发送,暂停发送的等待过程中,会给B定期发送窗口探测报文,这个报文不携带具体的业务数据,只是为了触发ack查询窗口大小~~
延时应答机制
创建一个TCP的socket,同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;
前面我们说过~网络上的传输可能后发先至
TCP使用这个接收缓冲区,对接收的数据进行重新排序,使应用程序read到的数据是保证有序的(和发送顺序一致)
既可以读数据,也可以写数据。
首先要明确,粘包问题中的 "包" ,是指的应用层的数据包。
在TCP的协议头中,没有如同UDP一样的 "报文长度" 这样的字段,但是有一个序号这样的字 段。
站在传输层的角度,TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
站在应用层的角度,看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分,是一个 完整的应用层数据包。
那么如何避免粘包问题呢?
归根结底就是一句话,明确两个包之间的边界。
对于定长的包,保证每次都按固定大小读取即可;
就从缓冲区从头开始按sizeof()依次读取即可;
对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位 置;
对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定 的,只要保证分隔符不和正文冲突即可);
协议头格式如下:
4位版本号(version):指定IP协议的版本,对于IPv4来说,就是4。
4位头部长度(header length):IP头部的长度是多少个32bit,也就是 length * 4 的字节 数。4bit表示最大的数字是15,因此IP头部最大长度是60字节。
8位服务类型(Type Of Service):3位优先权字段(已经弃用),4位TOS字段,和1位保留 字段(必须置为0)。4位TOS分别表示:最小延时,最大吞吐量,最高可靠性,最小成本。 这四者相互冲突,只能选择一个。对于ssh/telnet这样的应用程序,最小延时比较重要;对于 ftp这样的程序,最大吞吐量比较重要。
16位总长度(total length):IP数据报整体占多少个字节。
16位标识(id):唯一的标识主机发送的报文。如果IP报文在数据链路层被分片了,那么每 一个片里面的这个id都是相同的。
16位头部校验和:使用CRC进行校验,来鉴别头部是否损坏。
32位源地址和32位目标地址:表示发送端和接收端。
我们来想一个问题~如果IP地址不够用了怎么办?
1.动态分配IP地址。此时就可以省下一大批IP地址了,但是这个方案没有从根本上增加IP地址,只是提高了利用率,治标不治本~
2.NAT网络地址转换,本质是使用一个IP地址代表一批设备,使用端口号区分,能够大大提高IP地址的利用率
3.IPv6 (从根本解决IP不够用的问题)
使用16字节,表示IP地址,
特殊的IP地址:
路由选择
mac地址是6个字节的(比IPv4地址大很多)当前每个设备都有一个唯一的mac地址,不是动态分配的,而是网卡出厂的时候设置好的
MTU :
关于网络原理这块知识点,会有一个常考的面试题:
在浏览器输入www.baidu.com并按下回车后,到最终页面展示,涉及了许多网络原理和技术,以下是整个过程的简要步骤:
1. DNS解析:
- 浏览器首先会将输入的URL解析成IP地址。这个过程称为DNS解析,它通过查询域名系统(DNS)来找到与www.baidu.com相关联的IP地址。
2. 建立TCP连接:
- 一旦浏览器知道了目标服务器的IP地址,它会尝试与该服务器建立TCP连接。这是通过三次握手过程完成的,包括客户端向服务器发送连接请求,服务器回复确认,然后客户端再次确认。
3. 发起HTTP请求:
- 一旦建立了TCP连接,浏览器将发起一个HTTP请求,以获取与www.baidu.com关联的网页。这个请求包含了要获取的页面信息,以及其他相关的HTTP头部信息。
4. 服务器处理请求:
- 目标服务器(www.baidu.com)收到浏览器的请求后,会根据请求的内容和服务器上的配置来处理请求。通常,服务器会生成响应,包括网页内容、状态码和其他HTTP头部信息。
5. 服务器发送HTTP响应:
- 一旦服务器处理完请求,它会将HTTP响应发送回客户端(浏览器)。这个响应包括HTTP状态码,例如200 OK表示成功,以及请求的网页内容。
6. 浏览器渲染页面:
- 浏览器接收到HTTP响应后,会解析HTML、CSS和JavaScript代码,然后渲染页面。这包括将HTML结构转化为可见的网页,并加载和执行JavaScript代码以添加交互性和动态内容。
7. 页面展示:
- 最终,浏览器将完整的网页渲染出来,并将其呈现在用户的屏幕上,用户可以看到和与网页交互。