计算机网络

OSI七层协议

1、应用层

网络的具体应用

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。

应用层协议：域名系统DNS，支持万维网应用的 HTTP协议

我们把应用层交互的数据单元称为报文。

---

域名系统：它作为可以将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

HTTP协议: 超文本传输协议是互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。

2、 表示层

表示层主要对接收的数据进行解释、加密、解密等，把计算机能够识别的内容转换成人能够识别的内容（图片、声音、文字）

3、会话层

在传输层的基础上建立连接和管理会话。

4、 运输层

运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。

运输层主要使用以下两种协议:

• 传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
• 用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

5、网络层

在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。

在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

6、数据链路层

两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。

在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

7、物理层

在物理层上所传送的数据单位是比特。

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

HTTP报文

HTTP请求报文：主要包括请求行、请求头部以及请求的数据三部分。

1、请求行：由方法字段、URL字段和HTTP协议版本字段。

2、请求头部：位于请求行的下面, 是一个个的key-value值。Host指出请求的目的地址；User-Agent是客户端的信息，检测浏览器类型的信息；Accept；Accept-Encoding；Accept-language。

3、空行(CR+LF)：请求报文用空行表示header和请求数据的分隔

请求数据：GET方法没有携带数据， POST方法会携带一个body

HTTP的响应报文：状态行，响应头部，相应的数据

1、状态行包括：HTTP版本号，状态码和状态值组成。（HTTP/1.2 200 ok）

2、响应头：类似请求头，是一系列key-value值。是客户端可以使用的一些信息，如：Date（生成响应的日期）、Content-Type（MIME类型及编码格式）、Connection（默认是长连接）等等

3、空白行：同上，响应报文也用空白行来分隔header和数据

4、响应体：响应的数据

200 OK                        //客户端请求成功
400 Bad Request               //客户端请求有语法错误，不能被服务				器所理解
401 Unauthorized              //请求未经授权，这个状态代码必须和	WWW-Authenticate报头域一起使用 
403 Forbidden                 //服务器收到请求，但是拒绝提供服务
404 Not Found                 //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error     //服务器发生不可预期的错误
503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

http 常⻅字段有哪些？

1、Host 字段：客户端发送请求时，用来指定服务器的域名
2、Content-Length：服务器返回数据时，会有这个字段，表明本次回应的数据长度。
3、connection：HTTP/1.1版本默认连接都是长连接，需要指定值为Keep-Alive。
4、Content-Type：用于服务器回应时，告诉客户端，本次的数据格式是什么

HTTP 和 HTTPS 什么区别？

1、 端口80 ， 443

2、安全性和资源消耗：HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

• HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
• HTTPS是运行在SSL之上的HTTP协议，SSL运行在TCP之上， 所有传输的内 容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。

对称加密算法和非对称加密算法

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称 加密算法有DES、AES等；

非对称密钥加密： 加密和解密使用不同的密钥。通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。可以更安全地将公开密钥传输给通信发送方；运算速度慢。典型的非对称加密算法有RSA、DSA等

HTTPS 采用的加密方式: HTTPS 采用混合的加密机制。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。

HTTP1.0、HTTP1.1、HTTP2.0

HTTP1.x有以下几个主要缺点：

• HTTP/1.0 一次只允许在一个TCP连接上发起一个请求、短连接

• 单向请求，只能由客户端发起。

• 请求报文与响应报文首部信息冗余量大

• 数据未压缩，导致数据的传输量大

HTTP2.0

二进制帧: HTTP/2 厉害的地方在于将HTTP/1 的文本格式改成二进制格式传输数据，极大提高了 HTTP 传输效率，而且二进制数据使用位运算能高效解析。

并发传输：HTTP/1.1 的实现是基于请求-响应模型的。同一个连接中，HTTP 完成一个事务（请求与响应），才能处理下一个事务，也就是说在发出请求等待响应的过程中，是没办法做其他事情的，如果响应迟迟不来，那么后续的请求是无法发送的，也造成了队头阻塞的问题。

HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

IO 多路复用模型中，线程首先发起 select 调用，询问内核数据是否准备就绪，等内核把数据准备好了，用户线程再发起 read 调用, read调用的过程（数据从内核空间->用户空间）还是阻塞的。

数据压缩：HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

服务器推送：HTTP/1.1 不支持服务器主动推送资源给客户端，都是由客户端向服务器发起请求后，才能获取到服务器响应的资源。

当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

HTTP长连接和短连接区别及应用场景

1、HTTP短连接

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。

当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

应用场景： WEB 网站的 http 服务一般都用短链接

因为长连接对于服务端来说会耗费一定的 资源，而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源， 如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

2.HTTP长连接

而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据 的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

长连接的优缺点：

• 长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间
• 对于频繁请求资源的客户来说，较适用长连接

应用场景： 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个 TCP 连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多， 所以每个操作完后都不断开，下次处理时直接发送数据包就 OK 了，不用建立 TCP 连接。

TCP三次握手

假设 A 为客户端，B 为服务器端。

首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。

A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。

B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。

A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。B 收到 A 的确认后，连接建立。

三次握手的目的是建立可靠的通信信道，三次握手最主要的目的就是双方确认自己与对方的 发送与接收是正常的。
第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

已经建立了连接，客户端出现故障了怎么办？

TCP 有一个机制是保活机制。这个机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。

TCP四次挥手

假设 A 为客户端，B 为服务器端。

A 发送连接释放报文，FIN=1。

B 收到之后发出确认，它发回一 个 ACK确认报文，确认序号为收到的序号加1。此时TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。

当 B 不再需要连接时，发送连接释放报文，FIN=1。

A 收到后发出ACK 确认报文，并将确认序号设置为收到序号加1，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。

B 收到 A 的确认后释放连接。

CLOSE-WAIT 状态问题：

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送FIN 连接释放报文。

TIME-WAIT 状态问题：

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

• 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。

• 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一 个新的连接不会出现旧的连接请求报文。
  通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。

TCP和UDP有什么区别？及其适用的场景。

用户数据报协议 UDP 是无连接的，远程主机在收到 UDP 报文后，不需要给出任何确认。 尽最大可能交付，支持一对一、一对多、多对一和多对多的交互通信。

UDP应用场景：

效率要求相对高，对准确性要求相对低的场景。QQ聊天、在线视频。

传输控制协议 TCP 在传送数据之前必须先建立连接，数据传送结束后要释放连接。 是面向连接的，提供可靠交付，有流量控制，拥塞控制，每一条 TCP 连接只能是点对点的（一对一）。

​ TCP应用场景：

效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、 排序等操作，相比之下效率没有UDP高。举几个例子：文件传输、接受邮件、远程登录、。

---

UDP为何快？

• 不需要建立连接
• 对于收到的数据，不用给出确认
• 没有超时重发机制
• 没有流量控制和拥塞控制

udp如何实现可靠性传输？

实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

实现确认机制、重传机制、窗口确认机制。

TCP 协议如何保证可靠传输

TCP重传

超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。

也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

超时触发重传存在的问题是，超时周期可能相对较长。

快速重传：

快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

快速重传机制只解决了一个问题，就是超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传之前的一个，还是重传所有的问题。

---

不知道该重传哪些 TCP 报文，于是就有 SACK 方法。这种方式有一个接受缓存区，可以发送给发送方，就可以知道哪些数据收到了。

D-SACK： Diplicate SACK

• 可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;
• 可以知道是不是「发送方」的数据包被网络延迟了;
• 可以知道网络中是不是把「发送方」的数据包给复制了;

滑动窗口

滑动窗口引入的概念

没有滑动窗口之前，TCP每发送一个数据，都要进行一次确认应答。当上一个数据收到应答之后，再发送下一个。这种模式的缺点是效率比较低。

为了解决这个问题，TCP引入了窗口这个概念。有了窗口，就可以指定窗口大小，窗口大小就是指不需要等待确认应答，而可以继续发送数据的最大值。

TCP 头里有一个字段叫 Window，也就是窗口大小。

这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

窗口的实现实际上就是操作系统开辟一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓存区中保留已经发送的数据。如果按期收到了确认应答，这个数据就可以从缓存中删除了。

累计确认模式：假如窗口大小为3个TCP段，发送方就可以连续发送3个TCP段，如果中间一个数据丢失了，只要发送方收到了最后一个ACK确认应答，就说明之前的数据都接收方都收到了，这种模式就叫做累计确认或者累计应答。

流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，来决定发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

拥塞控制

在网络出现拥堵时，如果继续发送大量数据包，可能导致数据包丢失、延迟，这时候TCP就会重传数据，重传之后就会导致网络的负担更加严重，造成更多的丢包。

就有了拥塞控制。

其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了用拥塞。

拥塞控制有哪些控制算法？

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。所以由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每收到一个ACK确认报文，这个值就加1，下次就会收到两个ACK，拥塞窗口就会增加到4，指数级别的增长。
• 拥塞避免：当拥塞窗口超过慢启动门限值（65536）之后，就会进入拥塞避免，变成线性增长，还是增长阶段，但是增长速度缓慢了一些。当网络出现丢包现象，这时候就需要对丢包进行重传，当触发了重传机制，就会使用「拥塞发生算法」。就会将慢启动门限设为原来的二分之一，拥塞窗口设置1。又回到慢启动。
• 快重传与快恢复：当网络状况好转之后，就是可以收到3个重复的ACK。进入快恢复阶段，拥塞窗口大小设置为慢启动门限，进入到拥塞避免阶段。

TCP 粘包

在浏览器中输入url地址

1、浏览器查找域名的IP地址，浏览器缓存查找、路由器缓存查找、DNS缓存查找

2、TCP连接：与服务器建立TCP连接。（发送数据在网络层使用IP协议，路由器在服务器通信的时候，需要将IP协议转换为MAC地址，需要使用ARP协议）

3、浏览器向服务器发送一个HTTP请求（HTTP：客户端浏览器与Web服务器之间的应用层通信协议，在TCP建立完成后，使用HTTP协议访问网页）

4、服务器处理请求并发回一个HTML响应

5、浏览器解析渲染页面

DNS解析过程，DNS劫持了解吗？

DNS完成的工作是：域名到IP地址的解析。将域名和IP地址相互映射的一个分布式数据库。

第一步：客户机提出域名解析请求，并将该请求发送给本地域名服务器。

第二步：当本地域名服务器收到请求后，就先查询本地缓存，如果有该记录项，则本地域名服务器就直接把查询结果返回。

第三步：如果本地缓存中没该记录，则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域(根子域)主域名服务器地址。

第四步：本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自 己的缓存，如果没该纪录，则返回相关下级域名服务器地址。

第五步：重复第四步，直到找到正确纪录。

第六步：本地域名服务器把返回结果保存到缓存，以备下一次使用，同时还将结果返回给客 户机。

DNS劫持： 在DNS服务器中，将www…com的域名对应的IP地址进行了变化。你解析出来的域名对应的IP，在劫持前后不一样。

HTTP劫持： 你DNS解析的域名的IP地址不变。在和网站交互过程中的劫持了你的请求。在网站发给你信息前就给你返回了请求。

DNS在区域传输的时候使用TCP协议,其他时候使用UDP协议。

GET和POST有什么不一样

GET和POST是HTTP请求的两种基本方法

1. GET在浏览器回退时是无害的，而POST会再次提交请求。

2. GET请求会被浏览器主动cache，而POST不会，除非手动设置。

3. GET请求在URL中传送的参数是有长度限制的，而POST么有。

4. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

5. GET参数通过URL传递，POST放在Request body中

session和cookie

Cookie 一般用来保存用户信息。

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息。Cookie其实还可以用在，登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。

Session 的主要作用就是通过服务端记录用户的状态，相对来说 Session 安全性更高。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。大部分情况下， 我们都是通过在 Cookie 中附加一个 Session ID 的方式来跟踪。

ARQ协议

自动重传请求，是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。 ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

Arp协议？

Arp协议能通过接收端的ip地址解析到mac地址。

如果发送端和目标端的主机都在同一个网段，发送端发送数据帧前检查是否拥有接收端的 mac地址，如果没有，则启动arp，先检查缓存ip-mac表中是否有接收端的mac地址，如果有 则直接拿来即用，如果没有则在本网段（局域网）广播arp包，本网段各计算机都收到arp请 求，从发送来的数据中检查请求过来的ip地址与自己是否一致，如果不一致，则丢弃，如果 ip一致，则单播返回mac地址给请求的计算机，发送端便获取到了接收端的mac地址，接收 到接收端的mac地址它还会缓存一份，用于下次拿来即用。

如果请求端和目标端的主机不在同一个网段呢？arp广播的数据是被路由阻断的，不能跨到不同的网段进行广播的，因为这样广播会导致广播数据泛滥。如果不在同一个网段，则请求端 拿到的目标端的mac地址其实是它网关的mac地址，将数据帧给到网关再进行下一跳转发， 下一跳同样在自己的网段寻找到目标主机mac地址或再找到下一跳mac地址。

DDos攻击了解吗？

分布式拒绝服务，一般来说是指攻击者利用一些被控制的设备对目标网站在较短的时间内发 起大量请求，大规模消耗目标网站的主机资源，让它无法正常服务。

什么是 TCP 半连接队列和全连接队列？

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

• 半连接队列，也称 SYN 队列；
• 全连接队列，也称 accepet 队列；

服务端收到客户端的SYN请求之后，内核会把该连接存储到半连接队列，并向客户端发送SYN+ACK，当客户端返回ACK后，服务端收到第三次握手的ACK后，就会建立完全的连接，将其加到accept队列。