文章目录
1、OSI七层参考模型
- 从底至上:物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
1.1、七层模型各自的功能和具有的协议
- 物理层:提供建立、维护和拆除物理链路所需的机械、电气、功能和规程的特性。在该层
数据还没有被组织,仅作为原始的位流或电气电压处理
。单位是比特
。 - 数据链路层:
- 封装成帧:在一段数据的前后分别添加首部和尾部。
- 可靠传输:
发送端
的数据链路层在数据中出现控制字符的前面插入一个转义字符
。接收端
的数据链路层在将数据发送到网络层之前删除插入的转义字符
。 - 差错检测:采用CRC循环冗余检测对帧数据进行差错检测。
- MAC寻址:寻找地址是计算机网卡的MAC地址(物理地址),而不是IP地址。
- 协议:
- PPP协议
- CSMA协议
- Ethernet以太网协议
- HDLC协议
- 网络层:
- 路由与转发:按照
分布式算法
,根据从各相邻路由器所得到的的关于整个网络拓扑的变化情况,动态的改变选择的路由。 - 地址转换:IP地址=>MAC地址。
- 流量控制和拥塞控制
- 路由与转发:按照
- 协议:
- IP协议:提供不可靠、无连接的传送服务。
- ARP协议:地址解析协议。就是通过目标设备的IP地址查询目标设备的MAC地址。
- 传输层:为会话层提供透明可靠数据传输服务,
保证端到端的数据完整性
。
- 协议
- TCP:一种面向连接的、可靠、基于字节流的传输层通信协议。
- UDP: 一种无连接的传输层协议,提供面向事务的简单、不可靠的信息传送服务。
- 会话层
- 表示层
- 应用层:是计算机用户以及各种应用程序和网络之间的接口,功能是直接向用户提供服务,完成用户希望在网络上完成的各种工作。
- 协议:
- HTTP:超文本传输协议,基于TCP,用于从web服务器传输超文本到本地浏览器的传输协议。
- FTP:文件传输协议。
- SSH:安全外壳协议,建立在应用层和传输层基础上的安全协议。
2、HTTP是什么、特点、组成部分?
2.1、什么是HTTP及其特点
- HTTP是用于从
万维网服务器
传输超文本
到本地浏览器
的传输协议。是基于TCP/IP
通信协议来传递数据。 - 特点:
- 简单快速
- 灵活
- 无连接
- 无状态
- 支持
B/S
、C/S
模式
2.2、组成部分
- 请求协议信息:
请求行、请求头、空行、请求体
。
- 因为没有请求数据,所以就没有请求体。
- 响应协议信息:
状态行、响应头、空行、响应体
。
3、常见的状态码
- 100 Continue:表明请求到目前为止处理都很正常,客户端可以继续发送请求或者忽略这个响应。
- 200 Success:表示成功处理了请求。
- 301 Moved Permanently:永久性重定向。
- 302 Found:临时性重定向。
- 403 Forbidden:请求被服务器拒绝。
- 404 Not Found:服务器找不到请求的网页
- 500 Internal Server Error:服务器正在执行请求时发生错误。
3.1、301和302的区别
二者都表示重定向
,即:浏览器在拿到服务器返回的这个状态码之后会自动跳转到一个新的URL地址,这个地址可以从响应头部字段Location获取(用户看到的效果就是输入的地址A瞬间变为了地址B
)。- 301
永久重定向
。表示请求的资源已经被分配了新的URI,以后应使用资源现在所指的URI
。 - 302
临时重定向
。表示请求的资源已被分配新的URI,希望用户本次能使用这个新的URI进行访问
。
3.2、Forward和Redirect区别
- Forward:客户端发出的请求
被服务器内部进行转发,浏览器地址依然是之前的URL
。 - Redirect:实际上是
两次HTTP请求,服务器端在响应第一次请求的时候,让浏览器向另外一个URL发出请求,从而达到转发目的
。浏览器的地址是返回的URL。
4、HTTP协议发展历程
4.1、HTTP/1.0
- 默认使用
短连接
,也支持长连接,需要手动设置Connection:keep-alive
。客户端每个HTTP请求和响应都会开启和关闭一个单独的TCP连接
。
4.2、HTTP/1.1
- 默认是
长连接
。同一个客户端和服务端之间的连续多个HTTP请求和响应可以通过一个TCP连接来完成
。客户端在最后一个请求的时候,明确要求服务器关闭TCP连接。 - 增加了
host
域,如果请求头没有指定host,那么返回404。否则如果不加host仅仅依靠一个IP地址是无法区分请求是那个虚拟主机
。(一个物理主机可以存在多个虚拟主机)。
4.3、HTTP/2.0
- 所有数据都是以
二进制
进行传输。 - 服务器端
不再按照顺序
来返回处理后的数据。 - 新增
header信息压缩
以及推送等功能,提高了传输效率
。
5、HTTP和HTTPS的区别
- 端口:HTTP默认端口号为80,HTTPS默认端口号为443。
- 安全性:HTTP使用明文传输信息,数据未加密,安全性差。HTTPS传输使用SSL加密,安全性较好。
- 数字证书:HTTPS协议需要到CA机构申请数字证书,绝大多数是需要花钱申请的。
- 响应速度和资源消耗:HTTP响应速度快,消耗资源较少。HTTPS响应速度较慢,消耗资源较多,因为相比HTTP在TCP之上多了
SSL/TLS协议
,响应速度慢,资源消耗多。
5.1、HTTPS连接建立的过程
- 首先客户端给服务端发送一个请求。
服务器
给发送一个SSL证书给客户端
,内容包括证书的发布机构、有效期、所有者、签名以及公钥。客户端
对发来的公钥
进行真伪校验
,校验为真
就使用公钥对对称密钥加密
,然后将信息发送给服务器。服务器端
使用私钥
进行加密并使用对称密钥加密确认信息
发送给客户端
。- 随后客户端和服务器端就使用对称密钥进行信息传输。
5.2、HTTPS的工作过程(稍难)
前置:SSL/TLS中使用了非对称加密,对称加密,HASH算法同时借助了CA机构及其颁发的数字证书。
对称加密:一个秘钥,既可以加密也可以解密,优点是加解密速度快,适合对大量数据加密;缺点是使用前需要传输给另一个使用方,容易泄露。
非对称加密:分为私钥和公钥,私钥自己保存无需发送,公钥则是公开的,公钥加密的信息只有私钥能解密(反之亦然)。非对称加密加解密速度慢,只适合少量数据加密。
完整性校验算法(hash算法):同一数据计算结果相同,一旦数据被修改结果就会改变。通常用来检查数据是否被篡改。
数字签名:可以验证数据是否为意料中的对象所发出的,二是数据是否被篡改。数字签名是指发送方使用私钥将数据的hash值(数据摘要)进行加密后得到的结果。发送方发送数据时,将数字签名和数据一同发给接收方;接收方收到数据后使用hash算法也得到了一个数据摘要,同时使用公钥对发送方的数字签名进行解密,解密成功得到原数据摘要,两个数据摘要相同则说明数据没有被篡改,否则说明数据被篡改。
CA(Certification Authority,证书颁发机构):证书颁发机构负责颁发数字证书,同时他自己有一对公钥和私钥,公钥被提前安装在各个操作系统当中,私钥自己保存。
数字证书:数字证书包括证书颁发机构,证书有效期,公钥,主题(证书是颁发给谁了,一般是个人或公司名称或机构名称或公司网站的网址),指纹(对证书前面的明文内容使用指纹算法后得到)以及指纹算法(哈希算法),签名(对指纹使用CA的私钥加密得到)以及签名算法。
HTTPS请求实际上包含了两次HTTP传输,可以细分为 4 步:
1. 客户端
向服务器发起HTTPS请求
,发送自己支持的TLS版本、加密算法集以及一个随机码R1
。
2. 服务器
确定TLS版本和加密算法,连同数字证书和随机码R2一同发给客户端
。
3. 客户端验证数字证书
,先
使用CA公钥对证书签名解密得到原来的指纹信息,并根据证书明文内容结合指纹算法重新计算一份指纹,对比指纹是否一致,以此验证证书来源和完整性;并
验证证书是否过期以及域名是否与请求域名一致。证书验证不通过则给出相应提示。 证书验证通过后,客户端生成随机码R3并使用证书中服务器的公钥进行加密然后发送给服务端。同时使用算法根据随机码R1、R2和R3生成加密通信数据使用的对称加密秘钥。
4. 服务器在收到消息后使用私钥解密得到随机码R3
,同时利用相同算法根据随机码R1、R2和R3生成秘钥,至此双方都得到了用于加密通信数据的对称加密秘钥。
注:如果HTTPS
每次重连都要重新握手确定传输秘钥,就会很费时,可以进行优化。服务器会为每个浏览器维护一个session对象
并保存传输秘钥,在TLS
握手阶段服务器构造name为sessionid的cookie传给浏览器
,之后浏览器每次请求都会携带sessionid
,服务器会根据sessionid
找到相应的传输密钥,这样就不必要每次重新制作、传输密钥了!
6、GET和POST的区别
- 功能角度:
GET
一般用来从服务器上获取资源
,POST
一般用来在服务器上新增资源
。 - REST服务角度:
GET是幂等的,POST不是幂等的
。 - 请求参数的角度:GET请求的数据会
附加
在URL之后,POST请求会把提交的数据放置在HTTP请求报文的请求体
中。 - 安全角度:POST比GET安全。因为GET请求提交的数据将明文出现在
URL
上,POST请求参数在请求报文的请求体
中。 - 请求大小角度:GET请求长度受限于浏览器或者服务器对URL
长度限制
,POST请求理论上没有大小限制。
7、REST风格
- 是一种架构风格,全称
Representational State Transfer
(表现层状态转换
)。REST的应用场景绝大部分是WEB应用,那么都是基于HTTP的。 - 资源是网络上一个实体,或者是网络上一个具体信息,一个资源可以被URI
唯一标识
。表现层
可理解为资源的一种具体表现。 状态转换
是指客户端和服务端的交互过程中通过HTTP协议提供4个动作(GET、POST、PUT(更新资源)、DELETE)。RESTful API
就是符合REST
风格的API
。
8、 HTTP幂等性
- 幂等就是
对于同一个系统,在同样条件下,一次请求和重复多次请求对服务端资源影响是一致的
。 - 常见的幂等方法:
GET
、PUT
、DELETE
。 - 常见非幂等方法:
POST
、PATCH
。
9、HTTP请求方法有哪些?
常见的方法
方法 | 描述 |
---|---|
GET | 用于请求服务器响应某个资源,不应当对系统资源进行改变 |
POST | 用于将数据(表单等)提交 到服务器已创建新的资源 |
PUT | 将数据提交到服务器更新 之前存在 的资源 |
DELETE | 请求服务器删除 指定的资源 |
PATCH | 对PUT的补充,用来对已知资源进行局部更新 ;当资源不存在 的时候,会创建 新的资源 |
10、COOKIE和SESSION
10.1、Cookie
- Cookie:是
服务器发送到用户浏览器并保存在本地的一小块数据,会在浏览器下次向同一服务器再发起请求的时候回被携带并且发送到服务器上
。用于个性化设置、浏览器行为跟踪。
10.2、Session
- Session:由于
HTTP
是无状态的协议
,那么服务器要记录用户状态就要借助Session
机制。现目前Session
常见要借助Cookie
。服务器端创建一个Session
对象,同时
创建一个特殊的Cookie
对象(name
为JSESSIONID
,value
为Session
对象的ID
),将该Cookie
对象发送至浏览器。当浏览器端发起不是第一次次请求对同一服务器的时候,此时就会携带该name
为JSESSIONID
的Cookie
对象。服务器根据Cookie
的value(sessionid)
去查询对象的Session
对象,就可以区分不同的用户。(Seesion对象默认存活时间为30min)
10.3、区别
- 位置:cookie的数据信息存放在
客户端浏览器
,session的数据信息存放在服务器上。 - 存取方式:cookie只能保存
ASCII
编码的字符,session可以存放任意类型的数据。 - 有效期:cookie可以设置为
长时间保持
,session一般失效时间较短
,客户端关闭
或者session超时都会失效
。 - 隐私策略:cookie客户端可见,容易遭到不法窃取。session存储在服务端,安全性相比cookie好些。
- 存储大小:一个cookie保存数据
不能超过4KB
,一个站点最多保存20个cookie。session理论上没有上限,考虑到服务器的性能,session不要存放过多的东西,同时需要设置Session
删除机制。
11、浏览器输入URL地址到显示主页的过程?
- 首先根据
URL
进行域名解析,得到对应IP
地址。解析的时候,会先去
浏览器的DNS缓存
查看是否命中,没有命中再
查看操作DNS缓存(hosts文件)
是否命中,如果这两个都没有命中的话就会借助域名服务器进行解析。 - 位于应用层的浏览器封装好
HTTP
请求报文之后交给传输层的TCP协议
。 TCP协议
根据IP地址向服务器的80
端口发起三次握手以建立TCP
连接,随后将HTTP报文
作为自己的数据部分封装到TCP报文段
中发送出去。- 服务器上的
TCP协议
收到TCP
报文段之后进行拆包得到HTTP请求报文
,HTTP请求报文
随后被应用层程序读取、解析、处理之后,按照之前步骤响应数据给浏览器。 - 浏览器得到
HTTP响应报文
之后进行解析(HTTP响应报文需要封装成TCP报文段进行发送
),渲染并且显示给用户。
12、TCP报文段的首部格式
-
非常重要
每个TCP段都包含源端口号和目的端口号,这两个端口用来寻找发送方和接收方应用进程。那么这两个值加上IP首部中的源IP首部中的IP地址和目的端的IP地址就能唯一确定一个TCP
连接 -
为了实现可靠传输,
TCP
采用了面向字节流
的方式 -
TCP在发送数据的时候,是从发送缓存中取出一部分或者全部字节并给其添加一个首部使其成为
TCP报文段
之后进行发送。
首部各字段意义:
- 源端口:用来标识
发送该TCP报文段的应用进程
。 - 目的端口:用来标识
接收该TCP报文段的应用进程
。 - 序号:
指出本TCP报文段数据载荷的第一字节的序号
。
- 确认号
ack
:指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号,同时也是对之前收到的所有数据的确认
。 - 确认标志位
ACK
:TCP规定,在连接建立后所有传送的TCP报文段都必须把ACK置为1
。
举例:- TCP客户进程发送一个TCP报文段 。
- 序号201:表示该TCP报文段数据载荷的第一个字节的序号为201
- 假设数据载荷的长度为100字节。
- 确认号字段的取值为800:表示TCP客户进程收到了TCP服务进程发来的序号到799为止的全部数据。期望收到序号从800开始的数据。
- ACK=1:为了使确认号字段有效,ACK就必须置为1.
- TCP客户进程发送一个TCP报文段 。
- 数据偏移:该字段实际上是指出了TCP报文段的首部长度。
- 保留:为今后使用,目前应置为0.
- 窗口:指出发送本报文段的一方的接收窗口。
窗口值作为接收方让发送方设置其发送窗口的依据
,是以接收方的接收能力来控制发送方的发送能力,这就是流量控制。 - 校验和:检查范围包括TCP报文段的首部和数据载荷两部分。
- 同步标志位SYN:在TCP连接建立的时候用来
同步序号
。TCP规定SYN被设置为1的报文段不能携带数据,但要消耗掉一个序号
。 - 终止位FIN:用来释放TCP连接。
- 复位标志位RST:用来复位TCP连接。当其为1的时候,表示TCP连接出现异常,必须释放连接,然后再重新建立连接。同时还用来拒绝一个非法的报文段或者拒绝打开一个TCP连接。
- 推送标志位PSH:该位置置1的时候,希望尽快上交应用进程,不必等到接受缓存都填满之后再向上交付。
- 紧急控制位URG:该控制位需要配合紧急指针使用。
- 紧急指针:用来指明紧急数据长度。
当发送方有紧急数据的时候,可将紧急数据茶队到发送缓存的最前面并且立刻封装到一个TCP报文段中进行发送
。
13、三次握手
首先明白三次握手的目的:确认双方的接发能力是否正常
,同时指定双方的初始化序列号(ISN)为可靠传输做准备
。
- 过程(因为服务端处于监听状态,所以只能由客户端发起):
- 第一次握手:客户端给服务端发送一个
连接请求报文段
,在该报文段的首部指定了SYN=1
,同时初始化序列化ISN(seq=x)
。然后客户端进入SYN_SENT
(同步发送)状态。 - 第二次握手:服务端接收到
连接请求报文段
后,给客户端回传一个连接确认报文段
,在该文段的首部指定SYN=1,ACK=1,ack=x+1
,并且也选择初始化序列号为y
。随后服务器进入SYN_RCVD
(同步接收)状态。 - 第三次握手:客户端收到了
连接确认报文段
之后,回传给服务端一个确认报文段
,在该报文段首部指定ACK=1,ack=y+1,seq=x+1
。随后客户端进入ESTABLISHED
(连接已建立)状态。等服务器收到了该报文段之后,也进入ESTABLISHED
状态,这样完成了三次握手。 - 最后一次的TCP确认报文段为什么
seq=x+1,ack=y+1
?seq=x+1
是因为客户端的第一个TCP报文段的序号为x,且不携带数据,因此第二个报文段的序号就是x+1
。ack=y+1
是因为对服务端所选择的初始序号的确认。
- 第一次握手:客户端给服务端发送一个
TCP规定普通的TCP确认报文段是可以携带数据的,不携带数据就不消耗序号
。
13.1、为什么是三次握手?
- TCP建立连接的时候,通过三次能
防止历史连接的建立,能减少双方不必要的资源开销,能帮助双方同步初始化序列号
。 - 不采用两次的原因:无法防止历史连接的建立,会造成双方资源的浪费,也无法同步双方序列号。
- 不采用四次的原因:三次是理论上可靠连接的最少建立次数。
13.2、三次握手过程中能否携带数据?
第一次、第二次不能,因为发送的报文段的首部有同步标志位SYN。第三次可以携带。
13.3、SYN攻击是什么?
- 是典型的
DOS/DDOS
攻击,在建立TCP连接的时候,攻击方利用服务器资源是在第二次握手的时候进行分配
这一特点进行攻击。 SYN
攻击就是供给端在短时间内伪造大量不存在的IP地址
,并且向服务端不断发送连接请求报文段
,服务端回传连接确认报文段
,等到攻击方的确认报文段
。但是由于IP地址伪造的,必不可能等到,那么服务端就不断的重发直至超时,伪造的连接请求报文段
会导致大量的请求连接
长时间占用半连接队列
,使得正常的连接
请求会因为队满而被丢弃,这样就引起网络拥塞设置系统瘫痪。
13.3、第三次握手失败怎么办?
- 第三次握手失败就是最后一次握手的
确认报文段
在网络中丢失了。 - 服务端重传
连接确认报文段(第二次握手)
,如果重传达到指定次数还没有收到确认报文段
,服务端就会自动关闭这个连接。
14、四次挥手
- 在挥手的过程,只有被动方和主动方。四次挥手是指主动方和被动方断开
TCP
连接需要发送四个报文段。在挥手之前,双方都处于ESTABLISHED
状态。这里假设主动方是客户端,被动方是服务端。- 第一次挥手:客户端向服务端发送一个
连接释放报文段
,在该报文段的首部指明FIN=1,seq=u
。同时停止发送数据,主动关闭TCP
连接。随后客户端进入终止等待1
状态。 - 第二次挥手:服务端收到了客户端的
连接释放报文段
,回传一个确认报文段
,在该报文段首部指明ACK=1,ack=u+1,seq=v
,随后服务端进入关闭等待
状态。客户端收到服务端的确认报文段
之后,进入终止等待2
状态,等待服务端发出的连接释放报文段
。 - 第三次挥手:此时若服务器也想断开连接,那么和第一次挥手一样。服务端向客户端发送
连接释放报文段
,在该报文段首部指明FIN=1,ACK=1,seq=w,ack=u+1
,随后服务端进入最后确认
状态,等待客户端的确认报文段
。 - 第四次挥手:客户端收到
连接释放报文段
之后,同样向服务端发出确认报文段
,在本次报文段首部指明ACK=1,seq=u+1,ack=w+1
,此时客户端进入TIME_WAIT
状态。服务端收到该报文段之后,进入CLOSED
状态。客户端经过2*MSL
时间之后进入CLOSED
状态。此时TCP
连接完全释放。
- 第一次挥手:客户端向服务端发送一个
14.1、建立连接需要3次,为什么关闭连接要4次?
因为在第二次握手的时候,服务端回传的连接确认报文段
首部将一个ACK
和一个SYN
合并到一起发送给客户端的。而第二次挥手和第三次挥手是分开将ACK
和FIN
发送的。这是因为TCP
是全双工通信
,在主动发发送连接释放报文段
之后,可能被动方还要发送数据,所以不能关闭数据通道,因此被动方不能将确认报文段和连接释放报文段
合并发送给主动方。
14.2、等待2*MSL的意义?
MSL
是指报文在网络中存活的最大时间,超过就会被丢弃。- 能保证主动方发送的最后一个确认报文段能够到达被动方。
- 能防止
已失效的连接请求报文段
出现在新连接中。
15、TCP依靠哪些机制保证可靠传输
- 校验和:如果收到的报文段校验和有差错,将会被
丢弃
。 - 序号和确认应答标志位:
TCP
给发送的每一个报文段中都有序号字段
,每次接收方
收到数据后,都会对传输方进行确认应答
,即发送确认报文段(ACK)
,其中的确认号告诉发送方成功接收了哪些数据以及下一次请求的数据从哪里开始发
。除此之外,接收方可以根据序列号对数据包进行排序,把有序数据传送给应用层,并丢弃重复的数据。 - 超时重传:每发出一个报文段,就启动一个定时器,等待接收端的确认。
超时就重发这个报文段
。 - 约定最大报文段长度:在建立TCP连接的时候,双方可以在
头部选项字段
中约定最大报文段长度作为发送的单位
,理想的情况下是该长度的数据刚好
不被网络层分片。 - 流量控制:通过
滑动窗口机制
来实现。通过窗口大小来协调端对端的发送速度
,确保接收端
来得及接收,进而尽可能减少丢包。TCP的流量控制 - 拥塞控制:根据
全局网络
的拥塞程度来调整拥塞窗口大小
,改善网络拥塞程度,从而尽可能减少丢包。TCP的拥塞控制
发送窗口大小 = min(接收窗口,拥塞窗口)
16、拥塞控制有哪些算法?
-
慢开始:开始不清楚网络拥塞程度,防止一开始注入大量数据就造成拥塞,选择
从小到大
主键增大拥塞窗口(cwnd
)数值。初值为1,每经过一个传输轮次
,cwnd就加倍
。当cwnd达到门限值(ssthresh
),改用拥塞避免算法。 -
拥塞避免:每经过一次
传输轮次
就把发送方的cwnd加1
,这样cwnd就按照现行规律缓慢增长。
无论慢开始还是拥塞避免阶段,只要发送方判断网络出现了拥塞,就会把ssthresh
设置为出现拥塞的时候发送窗口值的一半(>2)
,然后cwnd重新设置为1,执行慢开始
。 -
快重传:要求
接收方
在收到一个失序
的报文段就立刻发出重复确认
而不要等到自己发送数据的时候捎带确认。 -
快恢复:发送方收到
三个
重复确认的时候,ssthresh
减半。此时执行慢开始,而是将cwnd
设置为ssthresh
的大小,接着执行拥塞避免。
16.1、拥塞控制和流量控制的区别?
- 流量控制:采用
端对端
的机制,接收端
通过窗口告知发送端自己的接收能力
,从而协调发送端的发送速度
,避免接收端来不及接收而产生丢包。 - 拥塞控制:采用
面向全局
的机制,根据网络拥塞程度来改变拥塞窗口
,从而协调主机向网络注入数据的速度,改善网络拥塞程度,尽可能减少丢包。
17、TCP和UDP的区别
类型 | 是否面向连接 | 传输是否可靠 | 传输形式 | 占用资源 | 是否支持多播,广播 | 首部长度(字节) | 应用场景 |
---|---|---|---|---|---|---|---|
TCP | 是 | 可靠 | 面向字节流 | 对系统资源要求较多 | 不支持(只能点到点) | 20-60 | 文件、邮件传输 |
UDP | 否 | 不可靠 | 面向报文段 | 对系统资源要求较少 | 支持 | 8 | 物联网、网络直播等 |
- TCP首部字段是因为
数值偏移
字段最小值为 ( 0101 ) 2 (0101)_2 (0101)2=5,最大值为 ( 1111 ) 2 (1111)_2 (1111)2=15,又因为单位是4字节,那么 5 ∗ 4 5*4 5∗4— 14 ∗ 4 14*4 14∗4。
18、TCP黏包
18.1、什么是TCP黏包
- 就是指发送方应用层交给
TCP
发送的若干数据包经过TCP
传输到达接收方的时候合并念成了一个数据包。
18.2、造成原因
- 发送方:
TCP
默认使用Nagle
算法,当应用层交付给TCP
发送的数据包过小
,发送方就会收集多个较小的数据包进行合并发送。 - 接收方:
TCP发送方
发送数据很快,接收方的TCP缓冲区
收到大量数据,但是应用层取出
数据速度太慢
,就造成多个数据包被缓存,应用层就有可能读取到多个首尾相接黏在一起的数据包。
18.3、如何解决
- 如果发送方发送的多个数据包本就是同一块数据不同部分,就不用处理。
- 如果发送的多个数据包毫无关系,那么就要进行处理(在发送方的应用层进行处理)。
- 在应用层交给
TCP
的每个数据包首部
添加长度字段,接收方应用层读取的时候就根据首部长度字段循环读取相应长度的内容; - 应用层交给
TCP
的每个数据包的首尾分别添加开始、结束符
。
- 在应用层交给
补充
1、可靠传输
- 使用差错检测技术,接收方数据的数据链路层就能够检测出帧在传输过程中是否产生了误码。
- 是否是可靠传输需要看数据链路层向上层提供的服务类型:
- 不可靠传输:仅仅丢弃有误码的帧,其他什么都不做。
- 可靠传输:想办法实现发送端发送什么接收端就接收什么。
- 可靠传输并不局限于数据链路层,其他各层均可以选择实现可靠传输。
2、IP地址、MAC地址、ARP协议
2.1、IP地址
- 现实世界要寄一封信,最重要的就是寄往何处,在计算机网络世界中的地址就是IP地址,有了该地址就能快速找到对应的设备。
- 当在浏览器上访问一个网站的时候,会首先使用这个网站地址去DNS进行解析,得到最终的IP地址,在互联网中,各路交换机会根据这个IP地址,最终把用户的请求送到对应的网络中。
- IP地址是唯一的,32位。
2.2、MAC地址
- MAC地址又称物理地址,每个网卡在生产的时候,每个生产商都会给自己的网卡分配一个唯一的ID。
- MAC理解为一个人的身份证。当然有些工具是可以篡改的。
- MAC地址只有在局域网中发挥作用。当有请求的网关的时候,网关便会想局域网内的机器进行呼叫,IP为XXX的哪台机器,对应的机器回复自己的MAC地址,之后网关就知道使用这台机器进行通信了。
- MAC可以被篡改,因此可能重复,在厂商烧网卡的时候,MAC地址是固定的,理论上MAC地址也是唯一的,48位。
举例:MAC地址就像身份证号码,具有唯一性,IP地址就像电话号码,可以有多个,不同场景下使用不同的电话号码(工作电话和四人电话),IP地址是有限的,内网和局域网通常都会共用一个对外的IP地址。
2.3、ARP协议
3、AQR协议
ARQ(自动重传请求)是OSI模型中
数据链路层和传输层
的错误纠正协议之一。利用确认和超时
两个机制,可以在不可靠服务的基础上实现可靠的信息传输。
ARQ协议主要包含:等待ARQ协议和连续ARQ协议。
- 等待ARQ协议相当于
发送窗口
和接受窗口
的大小均为1
的滑动窗口协议。即:发送一个帧,接收方接收了这个帧才能发送下一个帧
。 - 连续ARQ协议:就是为了克服等待ARQ协议长时间等待ACK的缺点,该协议会连续发送一组数据包,然后等到这些数据包的ACK。
回退N帧ARQ协议
:接收端丢弃第一个没有收到的数据包开始的所有数据包;发送端收到NACK后,从NACK中指明数据包开始重新发送选择性重传ARQ协议
:发送端连续发送数据包但每个数据包都设有一个计时器
;当在一定时间内没有收到某个数据包的ACK的时候,发送端需要重新发送那个没有ACK的数据包。