面试-计网

1.网络模型

        五层模型和七层模型，一般考察五层模型

        1.1 五层模型

        物理层：实现比特流的透明传输。

        数据链路层：将数据封装成帧在链路上进行传输

        网络层：选择合适的路由和节点进行分组传输，主要的协议有IP协议

        传输层：为进程之间的通信提供数据传输服务，主要的协议有传输控制协议TCP、用户数据报协议UDP

        应用层：为应用程序提供交互服务，这一层协议有很多，比如域名系统DNS、HTTP协议等

        1.2 七层模型

        物理层、数据链路层、网络层、传输层、会话层、表示层和应用层

        1.3 TCP/IP模型有哪几层

        1. 应用层（会话层、表示层、应用层）：负责向用户提供一组应用程序，比如HTTP、DNS、FTP等

        2. 传输层：负责端到端的通信，比如TCP、UDP等，存端口号

        3. 网络层：负责网络包的封装、分片、路由和转发等，比如IP、ICMP等

        4. 网络接口层（数据链路层和物理层）：负责网络包在物理网络中的传输，比如网络包的封帧、 MAC 寻址、差错检测，以及通过网卡传输网络帧等。

2.、知道IP地址和掩码怎么计算网络号和主机号

        IP地址与掩码按位与得到网络号，IP地址与掩码取反后按位与得到主机号

3、键入网址到网页显示之间的过程

        3.1 解析URL，生成HTTP报文

        3.2 通过DNS查询域名对应的IP地址

                域名解析工作流程：

                1.浏览器搜索自己的DNS缓存

                2.如果没有，就搜索操作系统中的DNS缓存和host文件

                3.如果没有，操作系统将域名发送给本地域名服务器，本地域名服务器会查询自己的缓存，如果没有就会依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终返回ip地址给本地域名服务器

                4.本地域名服务器会将IP地址缓存并发送给操作系统，操作系统也会缓存并发送给浏览器。

        3.3 将HTTP消息通过TCP进行传输（添加了TCP头部），在TCP头部中有源端口号和目标端口号。

        3.4 通过IP协议将数据封装为IP数据包（添加IP头部），在IP头部里面有源地址IP和目标地址IP。

        3.5 为IP数据包添加MAC头部，在MAC头部里包含发送方和接收方的MAC地址，用于两点间的通信。

        3.6 通过网卡，将数字信号转为电信号发送出去。

        3.7 交换机通过MAC地址表查询MAC地址，将信号发送到相应的端口上

        3.8 通过路由器进行转发

        3.9 到达服务器后对数据进行解析，判断MAC地址、IP地址等，如果都没有问题，就通过HTTP将数据封装为响应报文，之后层层封装发送回客户端。

4、HTTP

        4.1 HTTP是什么？

        HTTP为超文本传输协议，超文本可以是文字、图片、视频等。HTTP是传输文字、图片、视频等超文本的一种规范协议。

        4.2 HTTP常见状态码

状态码	含义	常见状态码
1xx	提示信息，表示处于协议处理的中间状态，还需后续操作
2xx	成功，报文已收到并成功处理	200/204/206
3xx	重定向，表示客户端需要重新发送请求	301/302/304
4xx	客户端错误	400/403/404
5xx	服务端错误	500/501/502/503

        301：永久重定向  302：临时重定向

        403：服务端禁止访问资源  404：请求的资源（比如页面）找不到

        502：服务器作为网关或代理时返回的错误码，表示服务器正常，但是后端服务器出错

        503：表示服务器繁忙，暂时无法响应

        4.3 GET和POST的区别

        按照RFC规范，GET是从服务器中访问资源，POST是根据请求对资源进行修改。

        安全幂等的含义：安全指的是请求不会破坏服务器上的资源，幂等指的是多次相同的请求结果都是一样的。

        1.GET是安全幂等的，POST不是

        2.GET请求参数通过URL传递，POS的请求参数放在请求体里面

        3.GET请求会被浏览器主动缓存，POST不会

        4.4 HTTP缓存技术

        1.强制缓存

        强制缓存指的是只要缓存没有过期，就直接使用浏览器本地缓存，决定权在浏览器

        2.协商缓存

        协商缓存指的是浏览器向服务器发送请求后，由服务器判断缓存是否可用，如果可用，就直接使用本地缓存。比如客户端第一次向服务端发送请求后，在本地对资源进行了缓存。第二次发送相同的请求，但是资源过期了，于是需要服务端比较请求的资源和本地资源是否一致，一致的话就让浏览器直接使用本地缓存的资源。也就是说当强制缓存未命中之后才会进行协商缓存。

        4.5 HTTP/1.1的优缺点

        简单灵活，无状态能减轻服务器的负担但在完成关联性操作会比较麻烦，明文传输不安全，不验证通信方身份，无法证明报文的完整性。采用长连接，只要其中一方没有提出断开连接就会一直保持连接，减少了TCP连接重复连接断开的开销，减轻了服务器负担。

        4.6 HTTP和HTTPS的区别

        1.HTTP是明文传输，HTTPS通过SSL/TLS进行加密传输，更安全

        2.HTTP端口为80，HTTPS使用443

        3.HTTPS协议需要向CA机构申请数字证书，保证服务器身份的可信

        4.7 HTTP报文格式

        请求报文由请求行、请求头、请求体组成，请求行里面包含URL

        响应报文由状态行、响应头、响应体组成，状态行包含状态码

5、TCP

        5.1 TCP头部格式

        TCP头部主要包含源端口号、目标端口号、序列号、确认应答号、标志位等部分。其中序列号用来解决网络包乱序问题，确认应答号用来解决丢包问题。标志位SYN为1表示希望连接，FIN为1表示希望断开连接，RST表示出现异常强制断开。

        5.2 TCP是什么

        TCP是面向连接的、可靠的、基于字节流的传输层通信协议，并且TCP是一对一进行连接的。

        5.3 UDP头部

        UDP头部大小为8个字节，由源端口号、目标端口号、包长度和校验和组成。其中端口号用于告诉UDP协议将报文发给哪个进程。包长度保存了UDP头部长度和数据长度之和，校验和用于提供可靠的UDP首部和数据，防止在网络中传输受损的UDP包。

        5.4 TCP和UDP的区别

        1.TCP是面向连接的，UDP是无连接的

        2.TCP是一对一的，UDP支持一对一、一对多和多对多的通信方式

        3.TCP有拥塞控制和流量控制，UDP没有，因此即使网络堵塞也源主机也不会降低发送效率

        4.TCP在没有选项字段头部需要20个字节，UDP头部占8个字节

        5.TCP面向字节流，而UDP是面向报文

        6.TCP提供可靠的服务，UDP不保证可靠的交付

        5.5 TCP和UDP应用场景

        TCP用于FTP文件传输、HTTP/HTTPS等，UDP经常用于包比较少的通信，比如DNS、SNMP等，经常用于视频、音频的通信和广播通信。

        5.6 三次握手

        首先客户端和服务端都是关闭状态，之后服务端会进入到监听状态。客户端向服务端发送请求连接报文后，会进入到SYN-SEND的状态，在这个报文里面会包含客户端随机生成的序列号x，会将标志位syn置为1。服务端接收到这个报文后，会进入到SYN-RECY的状态，并且向客户端返回一段报文，这个报文里面包含服务端随机产生的序列号y，和确认应答号。确认应答号是客户端序列号x+1，此外还会将标志位syn和ack置为1。客户端在接收到这段报文后就会进入到ESTABLISHED的状态，并且向服务端返回一段报文，这段报文里面序列号是之前的序列号加一，也就是x+1，确认应答号是服务端序列号加一，也就是y+1，并且标志位ack置为1。服务端接收到这段报文后也会进入到ESTABLISHED的状态。

        5.7 四次挥手

        首先客户端和服务端都处于ESTABLISHED的状态。客户端向服务端发送希望断开连接的请求，之后会进入到FIN-WAIT1的状态。发送的报文中携带自身随机产生的序列号，并且将标志位FIN置为1。服务端在接收到这段报文后，会响应一段报文后进入到关闭等待的状态，因为可能还有任务没有处理完就不会立刻断连。在这段报文里面包含自身随机产生的序列号和确认应答号，确认应答号是客户端序列号加一，此外将标志位ACK置为1。客户端再接收到这段报文后会进入到FIN-WAIT2的状态。当服务端处理完任务后，会向客户端发送断开连接的报文，并进入到最终确认的状态。这段报文里包含随机产生的序列号，确认应答号是客户端序列号加一，FIN和ACK标志位都为1。客户端接收到这段报文后会返回确认断开的报文，并进入到时间等待的状态，等待2MSL之后会进入到关闭状态。客户端返回的报文里面包含自身的序列号和确认应答号，确认应答号是服务端序列号加一，此外标志位ACK会置为1，服务端接收到之后就会进入到关闭状态。

        5.8 为什么是三次握手，不是两次或者四次？

        三次握手可以同步双方的初始序列号，保证双方的发送和接收能力，能够避免历史连接初始化造成的混乱，此外可以避免资源的浪费。

        举个例子：假设客户端向服务端发送连接请求，但是网络拥塞一直没到达服务端，并且客户端宕机了。客户端重启之后再次向服务端发送新的连接请求，但是这个时候之前的请求连接这时候到达了服务端，服务端就会向客户端返回响应报文。如果是两次握手的话，服务端在接收到连接请求后就会进入到连接建立状态，并且向客户端发送数据，这就会造成资源浪费等问题。假设是三次握手，客户端接收到服务端响应请求之后，会判断这个连接的ack，如果不对的话就会向服务端发送RST报文终止连接。这样就避免了历史连接问题。

        由于三次握手就可以同步双方序列号了，因此没有必要四次

        5.9 为什么每次初始化TCP连接都要求序列号不一样？

        1.为了防止历史报文被下一个相同的四元组的连接接收

        2.防止黑客伪造的相同序列号的TCP报文被对方接收（没看明白）

        5.10 三次握手中其中一次握手丢失了，会如何处理

        假设建立连接发送方为客户端：

        1.第一次握手丢失了客户端会重传，直到收到服务端返回的报文或者达到最大重传次数

        2.第二次握手丢失也由客户端重传，直到收到服务端返回的报文或者达到最大重传次数

        3.第三次握手丢失由服务端重传，直到收到客户端返回的报文或者达到最大重传次数

        5.11 SYN攻击是什么？怎么解决？

        SYN攻击指的是攻击者在短时间向服务端发送伪造的SYN报文，导致服务端半连接队列溢出。

        解决办法：调大 netdev_max_backlog；增大 TCP 半连接队列；开启 tcp_syncookies；减少 SYN+ACK 重传次数。

        5.12 为什么是四次挥手不是三次

        因为当收到客户端断开连接的请求的时候，服务端可能还有数据没有处理，客户端此时也还可以接收数据，需要等到服务端将数据处理完之后，才能进行一个断连，因此服务端在接收到断连请求后并不会马上断开连接。这也是为什么需要四次挥手的原因。

        5.13 四次挥手中其中一次挥手丢失会如何处理？

        假设断开连接发送方为客户端：

        1.第一次挥手丢失由客户端重传，直到收到服务端的报文或者达到最大重传次数

        2.第二次挥手丢失由客户端重传，直到收到服务端的报文或者达到最大重传次数

        3.第三次挥手丢失由服务端重传，直到收到客户端的报文或者达到最大重传次数

        4.第四次挥手丢失由服务端重传，直到收到客户端的报文或者达到最大重传次数

        5.14 为什么要等2MSL

        MSL表示的是报文的最大存活时间，假设不等2MSL直接进行关闭，那么假设被动关闭方没有收到最后一次确认关闭的报文，那么即使触发重传操作，由于这个时候主动关闭方已经处于关闭状态了，没办法接收报文并确认，这就导致被动关闭方无法正常关闭。

        此外，可以使历史连接的所有报文段都失效，这样就不会影响下一次连接。

        5.15 为什么是2MSL

        假设被动关闭方没有接收到最后确认关闭的请求报文，那么会进行重传，然后再次接收FIN报文，一来一回最大时间为2MSL。

        5.16 超时重传

        当发送方数据包丢失或者接收方的确认应答丢失的时候，会触发发送方进行超时重传。 超时重传的时间设置为RTO，略大于RTT，RTT为数据包的往返时延。如果RTO设置的太小了，会导致数据还没发到就重传导致网络拥塞，如果设置太大了效率会比较低。此外，每一次超时重传的时候，会将下一次的间隔时间设置为上一次的两倍。

        5.17 快速重传

        当接收到三个相同的ACK的时候，在定时器过期前重传丢失的报文。但是存在是只重传这个丢失的报文还是重传这个报文之后所有的报文的问题，因为不知道是哪些数据丢失了。只重传一个的话，这个丢失的报文下一个又需要接收到三个相同的ack来进行重传，如果重传所有的话，又会产生重复，浪费资源。

        5.18 SACK方法

        通过再TCP头部选项这个字段中存储已经接收到的信息，并将这个信息返回给发送方，这样就知道应该重传哪些数据了。

        5.19 Duplicate SACK

        使用SACK来告诉发送方哪些数据被重复接收了。

        5.20 滑动窗口和流量控制

        TCP通过滑动窗口来实现流量控制，流量控制是为了控制发送方的速率，保证接收方来得及接收。滑动窗口的窗口大小指的就是无需等待确认应答，可以继续发送数据的最大值。比如滑动窗口是3，那么可以在没收到ack之前发送三个报文过去。发送方的窗口大小由接收方控制，接收方会向发送方发送确认报文，报文里面携带window字段表示接收方能够接收数据的大小，通过window字段就可以控制发送方窗口大小。接收方窗口大小取决于应用、系统和硬件的限制。

        举个例子，假设客户端向服务端请求发送数据，假设客户端和服务端的窗口大小都是200.服务端接收到请求后会返回确认报文和80字节大小的数据，这个时候，服务端可用的窗口大小就变成了120。然后客户端接收到数据后窗口就会向右移动80个字节并向服务端发送确认报文。服务端在没有接收到确认报文的时候，可以继续发送数据，假设发送了120个字节的数据，这时候可用窗口就为0了，也就是不能继续发送数据了。当接收到客户端的确认报文后，服务端的窗口就可以向右移动80个字节，可用窗口大小也就变成了80。

        5.21 拥塞控制

        流量控制用于控制发送方速率，保证接收方能够来得及处理这些数据。但是在发送的过程中，网络可能会拥塞，如果网络拥堵但是继续发送数据，那么会导致更多的数据延时或者丢失，这又会导致重传，从而陷入恶性循环，因此需要用拥塞控制来解决这一问题。实现拥塞控制主要是通过慢启动、拥塞避免、超时重传、快重传和快恢复来实现的。

        慢启动：每接收到一个ACK拥塞窗口cwnd就加一

        拥塞避免：当拥塞窗口cwnd达到慢启动门限ssthresh的时候会进入到拥塞避免算法，这时候每接收到一个ACK，拥塞窗口会增加拥塞窗口分之一的大小，即1/cwnd；

        拥塞发生：当拥塞发生的时候会进行重传。对于超时重传，会将慢启动门限设置为拥塞窗口的一半，然后将拥塞窗口大小置为拥塞窗口的初始值,之后进入到慢启动算法；但初始值一般会比较小，这样会造成网络卡顿，效率会比较低。因此，可以用快重传算法来解决。当连续收到三个相同的ack的时候就会发生快速重传，之后进入到快恢复算法；快恢复算法会将慢启动门限设置为拥塞窗口的一半，然后将拥塞窗口大小减半，之后进入到拥塞避免算法让拥塞窗口进行线性增长。

6、Cookie和Session

        由于HTTP是无状态的，对于每一次的请求，服务端无法知道客户端之前的状态。因此可以使用Cookie来保存会话状态。当客户端发送请求的时候，服务端会将状态数据以key-value的形式写入到cookie中并返回给客户端保存。客户端在下一次的请求中就会携带这个cookie到服务端，服务端通过cookie中的信息来识别客户端。session则是当客户端发送请求到服务器，服务器会生成sessionID保存到cookie中并返回给客户端缓存，客户端下一次发送请求的时候就会携带这个sessionID到服务端，服务端通过sessionID来查询用户，识别客户端身份信息。

        session相对cookie来说更加安全，但实际上也是不安全的，因为http本身就是不安全的。session将数据保存在服务端，这样数据就更不容易被恶意获取。

        cookie和session的区别主要有以下几点：

        1.cookie存放在客户端，但是session存放在服务端

        2.由于session存放在服务端，因此相对cookie来说更加安全，但是这也增加了服务端的压力

        3.cookie的大小有限制，不能超过4K；session没有限制

7、对称加密和非对称加密

        对称加密就是加密和解密用的是同一个秘钥；非对称加密需要用到四个秘钥。发送方和接收方各两持自己的公钥和私钥。公钥是公开的，非对称加密主要可以用于加密和签名。

        对于加密，举个例子，发送方A和接收方B都可以获取到对方的公钥并且保留自己的私钥在发送消息的时候，发送方A用接收方B的公钥加密，然后接收方B用自己的私钥解密。B给A发送消息的时候用A的公钥加密，之后A收到消息后用自己的私钥解密。

        对于签名，一般是用私钥进行加密，然后让公钥所有者验证私钥所有者的身份并且防止私钥所有者发布的内容被篡改。

8、数字签名和数字证书

        数字签名的过程是：B给A回信时，采用hash算法对内容信息进行hash运算得到摘要信息，之后用私钥进行加密得到数字签名；再将数字签名附在要回的消息后面一起发送给A；A收到这个消息后，首先对数字签名用公钥解密得到摘要信息；再采用相同的hash算法对消息进行hash运算，与摘要信息对比，如果一致的话就说明内容没有被篡改。

        但是存在中间人攻击问题，如果是黑客伪造的数字签名和消息，我们用这个办法对比也是内容是一致的，我们没法确定发送者的身份是不是伪造的。这就需要用到数字证书。假设A发送自己的公钥给B的时候，黑客将这个公钥篡改成自己的，那么B在收到消息进行解密的时候用的就是黑客的公钥，也就是说黑客可以伪造数字签名和信息。

        数字证书就相当于身份证，我们可以通过数字证书来判断公钥是不是发送方的。