计算机网络

runzhi_z

于 2020-08-10 18:03:01 发布

阅读量165

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/womuz/article/details/107820981

版权

计算机网络专栏收录该内容

4 篇文章 0 订阅

订阅专栏

计算机网络

七层网络模型

七层网络模型的作用、协议
https://blog.csdn.net/yaopeng_2005/article/details/7064869

物理层 – 利用传输介质为数据链路层提供物理连接，实现比特流的传输
数据链路层 – 接收来自物理层的位流形式的数据，封装成帧，传输到上一层，还负责处理接收端发回的确认帧的信息，通过差错控制和流量控制将有差错的物理线路转换为无差错的数据链路，实现可靠的数据传输
网络层 – 将数据链路层数据转换为数据包，从一个网络设备传送到另一个网络设备，实现不同子网之间的通信
传输层 – 提供可靠的端到端的数据传输
会话层 – 管理网络设备间的会话
表示层 – 对来自应用层的数据进行解释，并按照一定的格式将数据传输给会话层（数据的加密解密等）
应用层 – 为用户提供服务，完成用户请求的各种服务

网络层

IP

IP地址由32位二进制整数组成，包括网络标识部分和主机标识部分组成，同一个网络内的网络标识相同，主机标识不同，可以通过子网掩码来区分，子网掩码部分网络标识部分为1，主机标识部分为0

传输层

主要TCP/UDP考点

区别

TCP面向数据流，UDP面向报文；TCP面向连接服务，传输数据之前建立连接，数据传输结束之后断开连接，UDP是无连接的数据传输；TCP通过三次握手、四次挥手建立断开连接，并进行流量控制和拥塞控制，实现了可靠的数据传输，而UDP数据传输的可靠性较低，但实时性高，故TCP适合对可靠性要求高的数据传输，UDP适合实时性要求高的数据传输；TCP只能一对一通信，UDP可一对多、多对一、多对多通信。

三次握手

参考：https://blog.csdn.net/hyg0811/article/details/102366854

三次握手

第一次：客户端给服务端发送SYN报文，并指明客户端的初始化序列号，SYN=1，seq=x
第二次：服务端接收到客户端的SYN报文之后，以自己的SYN报文作为应答，并指明自己的初始化序列号，同时将客户端的初始化序列号+1作为ACK的值，表明自己接收到客户端的SYN报文，SYN=1，ACK=1，seq=y，ack-x+1
第三次：客户端接收到SYN报文之后，会再发送一个ACK报文，将服务端的初始化序列号+1作为ACK值，表明接收到服务端的SYN报文，ACK=1，ack=y+1，seq=x+1

为什么需要三次，两次不可以吗？

三次握手主要作用：保证双方都具备接收和发送数据的能力，同步双方的初始序列号
仅两次握手来建立连接，可能会出现如下问题：
1⃣️ 资源的浪费：1.两次握手服务端每收到一个SYN数据包主动建立连接，如果客户端发送的SYN数据包在网络中阻塞，客户端会重新发送SYN数据包，造成服务端建立多个无效的连接，资源浪费； 2. 失效的SYN请求延时发送到服务端，造成服务端资源的浪费，（旧的SYN数据包造成连接混乱和资源浪费）例如：客户端发送请求。请求丢失，客户端重新发送请求，双方建立连接，传输数据，断开连接，断开连接之后，第一次丢失的SYN报文在网络中滞留发送到了服务端，服务端误以为客户端发起了新的请求，返回确认报文建立连接，但是客户端对服务端返回的确认报文不理会，服务端等待客户端发送数据，造成资源浪费。
2⃣️ 确保双方的初始序列号被可靠的同步
2⃣️ 安全问题：SYN攻击（DDOS攻击的一种）-- （三次握手也存在该安全问题）

什么是半连接队列

服务器在第一次接收到客户端的SYN数据包后，双方还没有完全建立连接，服务器会并这种状态下的请求连接放在一个队列中，称之为半连接队列。
全连接队列：客户端和服务端经过三次握手，完全建立连接，放在全连接队列中，该队列满了之后可能会出现丢包现象。
SYN-ACK重传次数的问题：第二次握手时，服务端向客户端发送SYN-ACK数据包后，等待一段时间，没有收到客户端的确认信息，首次重传，等待一段时间若仍然没有收到客户端的确认信息，二次重传，若重传次数达到上限，则会将该连接信息从半连接队列中删除。

ISN（初始化序列号）是固定的吗

不是固定的，ISN是随时间变化的

三次握手过程中可以携带数据吗

第一次和第二次握手不可以携带数据，第三次可以。
第一次握手携带数据，会让服务端更容遭到攻击，例如：第一次握手携带数据，有人恶意攻击服务器，每次在SYN报文中携带大量数据，疯狂重复向服务端发送SYN报文，服务端端需要花费大量时间内存空间来接收这些报文。

SYN攻击是什么？

SYN攻击：客户端在短时间内伪造大量不存在IP，向服务端发送SYN包，服务端回复确认包，等待客户端的应答，由于源地址是不存在的，服务器需要不断重发直到超时，这些伪造的SYN包长时间占用半连接队列，导致正常的SYN请求因为队列满而被丢弃。

四次挥手

四次挥手

建立连接需要三次握手，断开连接则需要四次挥手主要与TCP的半关闭有关。半关闭就是指：连接一端在结束数据发送（断开一端连接）之后仍然具备接收另一端数据的能力。
挥手客户端和服务端均可主动发起。
第一次：客户端发送FIN报文，报文中指定一个序号，停止发送数据，关闭TCP连接，客户端处于FIN_WAIT1状态
第二次：服务端接收到FIN报文后返回ACK报文，并以FIN中的序号+1为ACK值，发送给客户端，服务端处于CLOSE_WAIT状态，客户端接收到ACK报文后处于FIN_WAIT2状态，TCP处于半关闭状态，客户端到服务端的连接断开
第三次：服务器也想断开连接，想客户端发送FIN报文，服务端进入LAST_ACK状态
第四次：客户端接收到FIN报文后，返回ACK报文，客户端进入TIME_WAIT状态，等待一段时间（2MSL）确保服务端接收到ACK报文后，进入CLOSED状态，服务端接收到ACK报文后，关闭连接，进入CLOSED状态

为什么需要4次

握手时，服务端接收到客户端请求之后，可以同时发送SYN和ACK报文，三次握手即可完成连接的建立，但是断开连接时，服务端接收到客户端的FIN报文后只能先回复ACK报文，断开客户端到服务端的连接，不立即关闭服务端到客户端的连接，等到服务端需要断开与客户端的连接时，服务端再向客户端发送FIN报文，断开连接。

2MSL 的等待时间

MSL是报文最大生存时间，1⃣️ （确保ACK数据包到达服务端）防止由于客户端向服务端发送的ACK确认包丢失造成的服务端无法进入关闭状态，确保服务端能够接收到客户端最后发送的ACK确认包。客户端最后发送的ACK确认包若丢失，服务端没有接收到ACK确认包，会超时重传FIN_ACK包，客户端接收到之后，重传ACK包，重启计时器。2⃣️ 保证本次连接的所有数据都在网络中消失：否则可能出现的情况：例如：客户端断开与服务端的连接后又建立了新连接，两次连接的ip 端口都是相同的，前一次连接的数据包一部分可能还保存在网络中，这部分数据在新连接建立后，发送到服务端，服务端以为这是新连接发送的数据包，造成新旧连接的数据包的混淆。

TCP实现可靠数据传输的原理

TCP实现可靠的数据传输：

通过三次握手建立连接，四次挥手断开连接，来保证建立的传输信道是可信的。
利用连续ARQ协议来确保传输数据的正确性，滑动窗口协议来进行流量控制
拥塞控制
https://blog.csdn.net/guoweimelon/article/details/50879588

ARQ协议和滑动窗口协议

ARQ – 自动重传请求，使用确认和超时两个机制，发送一个数据时，启动计时器，发送方在一段时间内没有收到确认信息，重新发送。有两种：停止-等待ARQ协议和连续ARQ协议。
停止-等待ARQ协议：发送方发送数据之后，等待接收方确认，接收到接收方的确认信息之后，再继续发送数据。 – 信道利用率低
连续ARQ协议：每次发送一组数据，多组数据可以连续发送，发完一组数据之后无需等待可以继续发送。

连续ARQ协议结合滑动窗口协议来使用：
发送方和接收方都维护一个窗口，即为发送窗口和接收窗口，发送窗口中的分组数据可以连续发送出去，不需要等待对方的确认，发送方每接收到一个确认就可以将窗口向前移动一个分组的位置。接收方采用累计确认，不必对收到的分组进行逐个确认，而只需要对按序到达的最后一个分组进行确认即可。这种累计确认的缺点就是：不能正确的向发送方反映接收到的全部分组的信息，例如：发送5组数据，第三组数据丢失，接收方只能返回前两组的确认信息，第4 5组数据虽然接收到，但是接收方并不能返回这两组的确认信息给发送方，3 4 5组的数据都需要重传。
拥塞控制

慢开始：确定在避免引起网络拥塞的情况下，能一次性传输的数据的大小。（拥塞窗口、慢开始门限），初始时拥塞窗口设置为1，开始时，指数型增长拥塞窗口，当拥塞窗口达到慢开始门限时，拥塞窗口线性增长。当发生网络拥塞时，将慢开始门限改变为原来值的1/2，重复之前的操作。
https://blog.csdn.net/qq_36953135/article/details/77506009
快重传：连续接收到三个重复确认即可发起重传，不必等到为期设置的重传计时器到期。

快恢复

应用层

HTTP & HTTPS

http请求报文包括哪些部分

http请求报文：请求行（ – 请求方式、URL、协议版本）、请求头部、（空行）、请求主体
http响应报文：状态行（ – 协议版本、状态码、状态码描述）、消息报头、响应正文

状态码：

100 Continue – 继续请求
200 OK – 请求成功
301 – 永久重定向，请求资源被永久性的移动到新位置
302 – 临时重定向，（暂时性的）-- 这两个请求返回字段中都会包含location的响应，重定向的地址
303 – 请求资源被分配了新的URI
304 – （浏览器缓存），服务端资源为更新，直接使用浏览器的缓存资源
400 – 客户端请求报文存在语法错误
403 – 对请求资源的访问被浏览器拒绝，如：没有获得文件的访问权限
404 – 服务端访问资源不存在
405 – 指定的请求方式不能用于相应资源，响应信息中应该指出请求该资源支持的请求方法
500 – 服务器内部错误，服务器遇到错误无法完成请求
501 – 请求方法不被服务器支持，无法处理
502 – 服务器作为网关从上游服务器得到无效/错误响应
503 – 服务器无法使用
504 – 网关超时，没有及时从上游服务器收到响应

http不同版本

https://juejin.im/post/6844903923136856078#heading-6
（1）http0.9 版本：
只支持GET请求方式
没有请求头的概念
服务端相应之后立即断开TCP连接
（2）http1.0 版本：
新增了PUT、POST、DELETE等多种请求方式
添加了请求头、响应头的概念
扩充了传输内容的格式，图片、音视频、二进制等格式的信息都可以传输
特性：
无状态 – cookie/session机制来进行身份认证和状态记录
无连接 – 导致性能缺陷：1. 无法复用连接，每次发送请求都要进行一个TCP连接，网络利用率低；2. 队头阻塞，http1.0 规定前一个请求响应到达之后才能发送下一个请求，故前一个请求阻塞，后面的请求也会阻塞
（2）http1.1版本
长连接：新增了connection字段，设置keep-alive值来保持连接不断开
管道化：发送请求无需等待前面的请求响应返回再发送，响应的顺序还是按照请求的顺序，所以队头阻塞的问题还是存在的
缓存：增加字段cache-control（发送请求时，先查看是否有缓存）
断点传输：上传/下载较大的文件时，可以分割成多个部分分别进行上传/下载，遇到网络故障问题也可以从上次上传/下载的地方继续进行传输
（3）http2 版本
二进制分帧：http1.x 解析基于文本，http2之后将传输信息分割为更小的帧，对他们采用二进制编码
多路复用：http1.x中并发多个请求需要建立多个tcp连接，且浏览器tcp连接建立有数目限制，http2中同域名下所有通信都建立在单个tcp连接上，单个连接上的交错的请求响应互不干扰
头部压缩：减少头部信息传输占用资源
服务器推送：服务器向客户端推送资源，无需客户端明确的请求