计算机网络相关总结
OSI七层模型
1 | 7. 应用层:用户及程序和网络之间的接口,各种应用程序协议:HTTP、FTP、 |
HTTP相关
参考资料:
https://www.cnblogs.com/ranyonsue/p/5984001.html
https://www.cnblogs.com/jpfss/p/10984966.html
HTTP协议请求、响应的报文格式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40请求报文
请求行 POST /index.html HTTP/1.1 请求方式 请求url HTTP协议版本
请求头 HOST: www.XXX.com 请求Header,可以添加多个
User-Agent: Firefox/15.0
空行 空行,标志header已添加完,区分请求体
请求体 Username=admin 请求体,请求需要的数据,GET请求没有请请求体
响应报文
响应行 HTTP/1.1 200 OK HTTP协议版本 响应码 响应状态
响应头 Content-Encoding: gzip 响应header
Content-Type: text/html
空行 空行,区分header和响应体
响应体 body 请求返回的数据,用于展示/处理。
----------------------------------------------------------------------------------------------
1. 请求方式:GET、POST、HEAD、OPTIONS
2. HTTP版本:
3. 请求头:
- User-Agent:用户请求的代理软件,包括用户的操作系统,浏览器等相关属性
- Cookie:常用来表示请求者的身份。比如有些会话信息(SesssionId)会存在Cookie中。
- Accept:客户端接受什么类型的信息。类型用MIME表示。
- Accept-Charset:客户端接受什么字符集的文本内容。常用的如UTF-8,GBK,iso-8859-1等。
-......
4. 响应码及响应状态:
1XX:信息提示。表示请求已被服务器接受,但需要继续处理,范围为100~101。
2XX:请求成功。服务器成功处理了请求。范围为200~206。
3XX:客户端重定向。重定向状态码用于告诉客户端浏览器,访问的资源已被移动并告诉客户端新的资源位置。客户端收到重定向会重新对新资源发起请求。范围为300~305。
4XX:客户端信息错误。客户端可能发送了服务器无法处理的东西,比如请求的格式错误,或者请求了一个不存在的资源。范围为400~415。
5XX:服务器出错。客户端发送了有效的请求,但是服务器自身出现错误,比如Web程序运行出错。范围是500~505。
常见的响应码:
- 200:客户端请求成功。
- 302:重定向。
- 404:请求资源不存在。
- 400:请求语法错误,服务器无法理解。
- 403:服务器收到请求,但拒绝提供服务。
- 500:服务器内部错误。
- 503:服务器当前不能处理客户端请求,可能需要一段时间后才能恢复正常。
参考资料:https://www.cnblogs.com/jpfss/p/10984966.htmlHTTP/1.x 与HTTP/2.x的版本有什么变化?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21- HTTP/1.0:
请求方式新增了POST,DELETE,PUT,HEAD等方式
增添了请求头和响应头的概念,在通信中指定了 HTTP 协议版本号,以及其他的一些元信息 (比如: 状态码、权限、缓存、内容编码)
扩充了传输内容格式,图片、音视频资源、二进制等都可以进行传输
特点:
无状态:服务器不跟踪不记录请求过的状态,可以借助cookie/session机制来做身份认证和状态记录
无连接:浏览器每次请求都需要建立tcp连接:
无法复用连接每次发送请求,都需要进行一次tcp连接(即3次握手4次挥手),使得网络的利用率非常低
队头阻塞,HTTP 1.0 规定在前一个请求响应到达之后下一个请求才能发送,如果前一个阻塞,后面的请求也会阻塞的。
- HTTP/1.1:
长连接:Connection: keep-alive,新增Connection字段,默认保持长连接,后续继续通过此通道传输
管道化:基于上面的长连接,管道化可以不等第一个请求响应继续发送后面的请求,但响应的顺序还是按照请求的顺序返回,并未解决队头阻塞的问题
缓存处理:新增字段cache-control
断点传输
- HTTP/2.0:
二进制分帧:HTTP 1.x 的解析是基于文本,HTTP 2之后将所有传输的信息分割为更小的消息和帧,并对它们采用二进制格式的编码,提高传输效率
多路复用: 在共享TCP链接的基础上同时发送请求和响应
头部压缩: HTTP 是无状态的,每一个请求都需要头部信息标识这次请求相关信息,所以会造成传输很多重复的信息,当请求数量增大的时候,消耗的资源就会慢慢积累上去。所以 HTTP 2 可以维护一个头部信息字典,差量进行更新头信息,减少头部信息传输占用的资源。
服务器推送:服务器可以额外的向客户端推送资源,而无需客户端明确的请求HTTP与HTTPS的区别?
1
2
3
41. http是HTTP协议运行在TCP之上,信息是明文传输,https是HTTP协议运行在SSL/TLS之上,SSL/TLS在TCP之上,是具有安全性的ssl的加密传输协议。
2. http和https是不同的连接方式,端口号也不一样,http是80,https是443
3. https是由SSL+HTTP构建的可进行加密传输、身份验证的网络协议,比http安全。
4. https需要到CA申请证书HTTPS的加密原理?
如何验证证书的合法性?
1
2
3
4
5
6
7
8https如何保证安全又高效?
- https使用非对称加密算法来交换对称加密的密钥,最后使用对称加密算法来进行通信。
如何保证非对称加密时的安全性?
- 服务端发送证书来传递非对称加密的公钥。保证了公钥和私钥的保密性。
客户端怎么知道证书是不是真的?
- 客户端根据CA证书的公钥校验证书的数字签名来保证其合法性。
客户端的CA证书不会被伪造或泄露吗?
- CA证书是默认预装到浏览器和操作系统中的,所以CA证书的公钥是安全的。https中哪里用了对称加密,哪里用了非对称加密,对加密算法(如RSA)等是否有了解?
1
2
3
4
5非对称加密算法:RSA,DSA/DSS
对称加密算法:AES,RC4,3DES
HASH算法:MD5,SHA1,SHA256
你只要想:既然是加密,那肯定是不希望别人知道我的消息,所以只有我才能解密,所以可得出公钥负责加密,私钥负责解密;
同理,既然是签名,那肯定是不希望有人冒充我发消息,只有我才能发布这个签名,所以可得出私钥负责签名,公钥负责验证。在浏览器地址栏键入URL,按下回车之后会发生什么?
1
2
3
4
5
61、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2、解析出 IP 地址后,根据该 IP 地址和默认端口 80,和服务器建立TCP连接;
3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求,该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4、服务器对浏览器请求作出响应,并把对应的 html 文本发送给浏览器;
5、释放 TCP连接;
6、浏览器将该 html 文本并显示内容;http的断点续传
1
2
3
4
5
6
7
8
9
10HTTP1.1协议(RFC2616)中定义了断点续传相关的HTTP头 Range和Content-Range字段,比如:
客户端下载一个文件被中断,请求续传,在header中增加Range:bytes=512000(从文件的什么位置开始传输)
服务端接收到请求,返回的响应数据header中增加Content-Range:bytes 512000-/1024000(传输位置/总大小)
返回的响应数据的状态码206,而不是200
存在的问题:
文件资源发生了变化,续传的文件就会出现错误。
此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义,比如实现Last-Modified来标识文件的最后修改时间,这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头,可以使用ETag头来放置文件的唯一标识,比如文件的MD5值。
终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段,帮助服务端判别文件变化。
另外RFC2616中同时定义有一个If-Range头,终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时,通过If-Range中的内容进行校验,校验一致时返回206的续传回应,不一致时服务端则返回200回应,回应的内容为新的文件的全部数据。http与Socket的区别?
TCP/IP
TCP/IP 是互联网相关的各类协议族的总称,比如:TCP,UDP,IP,FTP,HTTP,ICMP,SMTP 等都属于 TCP/IP 族内的协议。
TCP/IP模型是互联网的基础,它是一系列网络协议的总称。这些协议可以划分为四层,分别为链路层、网络层、传输层和应用层。
1 | 链路层:负责封装和解封装IP报文,发送和接受ARP/RARP报文等。 |
TCP和UDP的区别?
1
2
3
4
5
6
7
8
9
10
11
12
13TCP:
- 面向连接:发送数据前建立连接(三次握手),为可靠传输打下基础
- 仅支持单向传播:TCP连接只能连接两个端点,所以不支持多播和广播的方式
- 面向字节流:TCP不像UDP一样那样一个个报文独立地传输,而是在不保留报文边界的情况下以字节流方式进行传输。
- 可靠的传输:判断丢包,误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据(假设丢失了)将会被重传。
- 提供拥塞控制:网络拥塞时,TCP可以减小向网络注入数据的速率及数量,减缓拥塞
- 提供全双工通讯:TCP允许通信双方的应用程序在任何时候都能发送数据,因为TCP连接的两端都设有缓存,用来临时存放双向通信的数据。当然,TCP可以立即发送一个数据段,也可以缓存一段时间以便一次发送更多的数据段(最大的数据段大小取决于MSS)
UDP:
- 面向无连接:无需建立连接,只是数据报文的搬运工,不会对数据报文做任何的拆分和拼接
- 由单播、多播、广播的功能
- 面向报文:UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此,应用程序必须选择合适大小的报文
- 不可靠性:无连接,没有拥塞控制,会丢包
- 头部开销小,数据报文传输更高效TCP连接的三次握手和四次挥手
https://www.cnblogs.com/AhuntSun-blog/p/12028636.html
首先要了解TCP的报文格式:
其中比较重要的字段有:
1 | (1)序号(sequence number):Seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。 |
三次握手
1 | 1. 首先客户端向服务端发送一段TCP报文: |
四次挥手
1 | |
首先客户端想要释放请求,向服务端发送一段TCP报文:
标记位为FIN,表示请求释放连接
序号Seq=U
随后客户端进入FIN—WAIT-1阶段,即半关闭阶段,停止客户端到服务端发送数据(不发送的是正常连接时传输的数据,仍可以发送ACK确认报文),但是客户端仍然能接收到从服务端传过来的数据服务端接收到客户端的TCP报文之后,确认客户端想要释放连接,随后服务端结束ESTABLISHED阶段,进入CLOSE-WAIT阶段(半关闭状态)并返回一段TCP报文:
标记位为ACK,表示接收到客户端发送的释放连接的请求
序号为Seq=V
确认号为Ack=U+1,在客户端发送的基础上,seq+1作为Ack值
客户端接收到从服务端发的报文后,确认服务端收到了释放连接的请求,随后客户端结束FIN-WAIT-1阶段,进入FIN-WAIT-2阶段。服务端发送完ACK确认报文之后,经过CLOSED-WAIT阶段,做好释放服务端到客户端方向上的连接准备,在向客户端发送一段报文:
标记位为FIN、ACK,表示已经准备好释放连接了
序号为Seq=W
确认号Ack=U+1,在客户端Seq基础上+1
随后服务端结束CLOSE-WAIT阶段,进入LAST-ACK阶段,停止到客户端发送数据,但是可以接收客户端传输的数据客户端收到服务端的TCP报文,确认服务端已经做好释放的准备,结束FIN-WAIT-2阶段,进入TIME-WAIT阶段,并向服务端发送一段报文:
标记位为ACK,表示接收到了释放信号
序号Seq=U+1
确认序号Ack=U+1
随后客户端在TIME-WAIT阶段等待2MSL
```1
2
4. 客户端在四次挥手TIME-WAIT最后为什么要等待2MSL?为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时,并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后,会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime:一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文,就会再次向客户端发出FIN报文;
如果客户端在2MSL内,再次收到了来自服务器端的FIN报文,说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文,计时器重置,重新开始2MSL的计时;
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文,说明服务器端正常接收了ACK确认报文,客户端可以进入CLOSED阶段,完成“四次挥手”。
所以,客户端要经历时长为2SML的TIME-WAIT阶段;这也是为什么客户端比服务器端晚进入CLOSED阶段的原因1
2
3
4
https://www.cnblogs.com/AhuntSun-blog/p/12037852.html
3. 拥塞控制和流量控制都是什么,有什么区别?如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。为了避免分组丢失,控制发送者的发送速度,使得接收者来得及接收,这就是流量控制。流量控制根本目的是防止分组丢失,它是构成TCP可靠性的一方面。
如何实现流量控制?
- 由滑动窗口协议(连续ARQ协议)实现。滑动窗口协议既保证了分组无差错、有序接收,也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小,并且利用大小来控制发送方的数据发送。
- 流量控制引发的死锁?怎么避免死锁的发生?
- 当发送者收到了一个窗口为0的应答,发送者便停止发送,等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失,发送者一直等待下去,而接收者以为发送者已经收到该应答,等待接收新数据,这样双方就相互等待,从而产生死锁。
- 为了避免流量控制引发的死锁,TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口,则重置该计时器继续等待;若窗口不为0,则表示应答报文丢失了,此时重置发送窗口后开始发送,这样就避免了死锁的产生。
拥塞控制和流量控制的区别 ?
- 拥塞控制:拥塞控制是作用于网络的,它是防止过多的数据注入到网络中,避免出现网络负载过大的情况;常用的方法就是:( 1 )慢开始、拥塞避免( 2 )快重传、快恢复。
- 流量控制:流量控制是作用于接收者的,它是控制发送者的发送速度从而使接收者来得及接收,防止分组丢失的
```