整理Android面经时遇到的计网相关的面试
网络模型
介绍一下七层模型和五层模型
OSI七层模式
自下而上：
物理层：负责传输比特流，保证数据通过物理介质传输；
链路层：负责MAC寻址（APR协议），并组合比特流（以太网协议）
网络层：负责不同网络之间数据传输和路径选择；
引入了IP地址，能够判断是否处于同一个局域网（子网内），建立主机到主机之间的连接；（IP协议）
传输层：负责端对端的通信（TCP、UDP协议），建立端口到到端口的连接；
会话层：负责管理通信会话的建立和管理；
表示层：负责数据的格式化和解析，将网络传输的数据解析为对应的格式；
应用层：为用户和应用程序提供网络服务接口，以及针对特定应用的协议（网络请求HTTP协议、远程登录SSH协议、文件传输协议FTP协议）
五层模型
相对于七层模式，将会话层、表示层、应用层统一合并为应用层；
让应用（开发者）来管理网络通信以及定义数据的解析；
网络层的协议介绍一个(?)
网络层主要负责不同网络之间的数据传输和路径选择，建立主机与主机之间的通信，通过引入IP地址来判断主机是否处于同一个局域网内；
IP协议：
为同一网络内的每一台主机分配唯一的IP地址，通过子网掩码来判断IP地址是否处于同一个网络下，实现路径选择；
将发送方和接收方的IP地址等信息保存在IP报文的标头中，主机与主机之间的通信
IP协议
网络层中为了解决不同局域网中主机的通信问题，在不同网络之间选择路由路径进行数据传输；
是不可靠的通信协议，不保证数据一定抵达，不对丢包进行任何处理；
IP数据报结构
0 4 8 16 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 版本 |首部长度| 服务类型 | 数据包总长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 标识 | 标志| 片偏移 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 生存时间 | 上层协议 | 首部校验和 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 源IP地址 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 目的IP地址 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 选项 ｜ 填充 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+版本占4位，表示IP数据包所使用的协议版本，通信双方使用的协议需要相同（4为IPv4,6为IPv6）
首部长度占4位，表示IP数据包首部的总长度，最后结果需要 *4
服务类型占8位，第4~7位为有效位，最多有一位设置为1，全部为0表示一般服务；
数据包总长度占16位，表示IP数据包的总长度，最大为65535个字节；
标识占16位，该IP数据包的唯一标识码，用于组装多个分片回同一个IP数据包；
标志占3位，只有后两位有效，第二位DF为表示是否不允许分片（1为不允许分片），第三位MR表示该分片后续是否还有分片（1为还有）
片位移占13位，表示该分片在整个IP数据包的偏移量；
生存时间占8位，表示该IP数据包在网络的最大存活时间，每经过一个路由器TTL都会减1，到0则丢弃；
上层协议占8位，表示该IP数据包的上层协议，比如UDP/TCP等
首部校验和占16位，表示IP数据包的首部的校验和；
TCP&UDP
TCP 和 UDP 都是传输层的协议，用于建立端对端（进程对进程）之间的通信，在计算机中每一个进程都会被分配一个端口，因此在这两个协议的标头中，都会包含发送方和接收方的 端口信息
结合网络层的IP协议，通过 (发送方IP地址、发送方端口、接收方IP地址、接收方端口）四元组来确定两个不同进程之间的通信；
TCP连接建立和释放
TCP连接需要三次握手，释放需要四次挥手
TCP三次握手的过程
第一次握手：客户端向服务端发送 TCP 报文，其 SYN =1，seq=X，等待服务端确认；（客户端SYN-SENT）
第二次握手：服务端接收到客户端发送的报文，确认连接后，向客户端发送一个SYN=1，ACK=1，seq=Y，ack=X+1的TCP报文，等待客户端确认；（服务端SYN-REVD）
第三次握手：客户端接收到服务端的报文后，向服务端发送一个ACK=1，seq=X+1，ack=Y+1 的报文；（客户端和服务端ESTABLSHED）
完成这三次握手，则认为服务端和客户端的 TCP 连接建立完毕
为什么需要三次握手？
假设 当客户端发送建立连接的报文，服务端返回一个确认建立连接的报文就能建立连接（二次握手）；
那么存在客户端发送建立连接的报文因网络原因，在客户端等待超时后抵达服务端；
服务端收到建立连接的报文后，返回确认连接的报文，但是客户端在等待超时后已经收回资源，对该报文并不处理，也就是说客户端不知道 TCP 连接已经建立，也就不会发送任何数据，服务端因等待客户端发送数据而导致资源浪费；
增加一次客户端的确认，也就是三次握手，能够有效避免上述情况的发生；
TCP握手期间可以携带数据吗？
第一次握手和第二次握手的报文段中不能携带数据，但是在第三次握手的报文段可以携带；
握手期间出现异常如何处理？
当在指定时间内未收到对方的ACK报文时，会触发TCP的超时重传机制，进行重发，重发是有次数限制的，而且每次重发之间的间隔都会增大；
如果服务端接收到 SYN 报文，但是客户端一直没有响应（可能是客户端没有收到服务器 ACK 报文，或者客户端发送的 ACK 报文丢失），在一定的重试次数后，就会自动关闭连接；
如果客户端发送的 ACK 报文丢了，此时就会进入 ESTABLISHED 状态，然后向服务器发送数据，此时服务器还在 SYN-REVD 状态，当收到数据时，根据报文中的 ack 号来确认是否收到了服务端发送的 SYN 报文；（ack号是对上一个对方发送的数据包的seq+1）
TCP四次挥手的过程
第一次挥手：客户端向服务端发送一个 FIN =1，seq=X的报文，表示自己已经没有任何数据要发送了；（客户端FIN-WAIT-1）
第二次挥手：服务端收到该报文后，开始准备连接的释放，向客户端发送 ACK=1，seq=Y，ack=X+1的报文；（服务端CLOSED-WAIT）
第三次挥手：服务端再次向客户端发送 FIN=1，ACK=1，seq=Z，ack=X+1的报文，表示服务端没有任何需要发送的数据，已经准备好释放连接；（客户端FIN-WAIT-2，服务端LAST-ACK）
第四次挥手：
客户端接受到报文后，向服务端发送 ACK=1，seq=X+1，ack=Z+1的报文，表示连接已经断开；（WAIT-TIME）
客户端将会等待 2MSL 时间，超过该时间后就会释放TCP 连接资源；（CLOSED）
为什么需要四次挥手？
因为 TCP 是 全双工 模式，服务端和客户端之间可以相互发送数据；
客户端发送 FIN 报文只是表示客户端没有数据要发送，而服务端可能还有数据需要发送，因此需要等待服务端发送完数据才能够断开连接；
当服务端发送完数据，即准备好断开连接后，向客户端发送 FIN 报文告知客户端可以断开连接；
为什么需要等待2MSL才断开连接？
为了确保服务器正确收到客户端发送的确认报文，进而保证TCP连接能够正确释放：
客户端发送的确认报文会丢失，服务端接受不到该报文后会进行重发，此时客户端如果关闭了连接，就会导致服务端找不到对应的连接进行重发，导致错误的发生；
客户端等待 2MSL 需要保证客户端发送的确认报文能到达服务端（1MSL），服务端重发报文能到达客户端（1MSL）
等待连接中的脏数据消除：
当客户端发送确认报文后立即关闭连接，再立即建立连接，此时可能新建立的连接是和先前断开的TCP连接相同
先前断开的连接中可能存在一些滞留的数据包，这些数据包会在新建立的连接后抵达客户端，而TCP协议因为该数据包的端口和IP相同就会接受，从而读到了脏数据，导致数据包混乱
四次挥手中如果出现了异常如何处理？（如果A要断开B没回复怎么办）
对于指定时间内没有接收到确认报文，是会触发TCP的超时重传机制的，如果超过指定次数都没有收到，就会直接关闭连接；
对于客户端发送的 FIN 报文服务端一直没有收到：
客户端超时重传后无效，断开连接；
服务端TCP连接超时后检测，关闭连接；
如果服务端发送的 ACK 报文客户端没有收到，且释放连接准备工作结束后发送了 FIN、ACK 报文：
客户端会重发 FIN 报文，在收到了 FIN、ACK 报文后会根据里面的 ack 号来确认已经收到；
客户端会发送 ACK 报文，并从 FIN-WAIT-1状态直接跳到 TIME-WAIT 状态
传输层的协议TCP和UDP介绍一下，TCP和UDP的区别？
TCP协议是面向连接、可靠的、基于字节流的通信协议，使用序列号、应答号、超时重传、慢启动、拥塞控制、流量控制等方法来保证数据传输的可靠性和顺序；
UDP协议是无连接、不可靠的、基于数据包的通信协议，不保证发送数据包的可靠性、完整性和顺序；
区别：
连接建立：
TCP在发送数据前需要通过三次握手建立连接，连接建立成功后才能发送数据
UDP在发送数据前无需建立任何连接，直接发送数据包；
数据可靠性：
TCP通过使用序列号、应答号、超时重传、慢启动、拥塞控制、流量控制来保证数据传输的有序性、完整性和可靠性；
UDP没有任何错误重试机制，不能保证数据传输的可靠性、完整性和顺序；
协议效率和开销：
TCP由于需要进行连接管理、错误检测和恢复，以及维持连接状态，其数据传输速度相对较慢，协议开销较大。
UDP无需建立连接，也没有错误重试，其数据传输速度较快，协议开销较小；
拥塞控制：
TCP会根据网络拥塞情况和接收方缓冲区大小来动态调节发送数据的速率；
UDP不管所处的网络状况直接发送数据包；
报文首部开销：
TCP报文首部需要20字节；
UDP报文首部只需8字节；
TCP是基于字节流发送数据的（发送窗口），而UDP是面向数据报的；
TCP是点对点（一对一）通信，而UDP支持一对一、一对多、多对多的通信；
介绍一下流量控制
流量控制是TCP协议用于防止网络拥塞，保证数据传输可靠性的一种方式：
发送方维护一个发送窗口决定单次发送的数据量，该发送窗口的大小由根据当前网络拥塞状况调节的拥塞窗口 和 接收方的 接收缓冲区大小 （报文中的窗口大小）两者的较小值；
当接收方的缓冲区大小较小时，会将减小发送窗口，避免接收方无法及时接收发送的数据导致丢包；
当网络拥塞时，也会减小窗口，避免因网络拥塞导致丢包或者数据破损；
发送窗口是一个滑动窗口，内部包含了已经发送但未确认的数据和未发送的数据，当发送的数据被确认时就会向前移动；
TCP如何保证通信稳定
序列号和应答号： 保证发送数据的顺序以及是否发生丢包
序列号能够让接收方组装这些数据；
应答号为接收方确认已经收到数据；
超时重传机制：当发送方在指定时间内未收到某份数据的应答报文，那么会将该份数据重新发送，直到对方接收；
去重机制：接收方接收到多份相同序列号的数据包时，将会丢弃重复部分的数据包；
拥塞控制：慢启动，并根据当前网路拥塞情况控制发送数据的速率；
流量控制：接收方在应答报文中可以携带当前接收缓冲区的剩余大小，发送方会根据该缓冲区大小以及拥塞窗口大小的较小值来控制发送数据的速率，保证对方可以平稳接收数据，不会因缓冲区或者网络拥塞而丢包；
TCP和UDP各自的应用场景？
TCP适合一些需要稳定性强、数据无法容忍缺失的场景，比如文件传输、
UDP适合一些实时性强的场景，比如音视频通话、视频会议、多人实时游戏、IM聊天
如何在弱网络的情况下优化TCP？
HTTP(s)
SSL， Secure Sockets Layer： 安全套接层
TLS，Transport Layer Security：传输层安全性协议；
讲一下HTTP协议
Http协议是基于 TCP 协议的应用层协议，全称叫做 超文本传输协议
协议：规定了通信的行为约定和规范；
传输：允许在两点之间传输数据；
超文本：允许传输各种类型的数据，而不只是文本；
特点：
无连接：每一次请求时都需要建立 TCP 连接，在请求结束后会立即断开连接
无状态：对事务处理没有记忆能力，会话结束后服务端都不会保留任何的会话信息；
灵活：通过 Content-Type 头部字段可以传输各种类型的数据
客户端/服务端模型：由客户端发起请求，服务端只能接受请求并返回响应内容；
Https协议，如何加密？与HTTP区别
HTTP通过SSL/TLS层进行加密和验证身份，
三次握手后双方准备开始生成会话秘钥，开始进行TLS的握手流程；根据不同的密钥交换算法有不同的握手流程
RSA交换算法：（TLS1.3废弃）
客户端向服务端发送随机生成的client-random、TLS版本、支持的加密套件；
服务端向客户端发送随机生成的server-randowm、TLS版本、加密套件、证书、数字签名；
客户端对服务器的证书进行校验：
使用相同的算法对证书进行摘要
使用浏览器或者操作系统内置的CA根证书的公钥去解密证书签名；
与先前的生成的摘要进行比较，如果相同则信任证书；
客户端向服务端发送一个随机生成的pre-master，并用服务器公钥进行加密；
服务端用自己的私钥解密得到pre-master；
客户端和服务端基于 client-random、server-random、pre-master 三种随机数进行混合加密得到会话密钥；
客户端向服务端发送加密算法更改通知，告知之后改用会话秘钥进行加密；并发送前面握手数据的摘要供服务端验证；
服务端向客户端段发送加密算法更改通知，告知之后改用会话秘钥进行加密；并发送之前握手数据的摘要供客户端验证；
如果服务器的公钥泄露，前面所发送的数据都可以计算出其 pre-master 值，进而解密出所有的数据；
ECDHE算法：
客户端向服务端发送随机生成的 client-random、client-param、TLS版本号以及支持的加密套件列表；
服务端接收到客户端后向客户端发送随机生成的 server-random、server-param、TLS版本、证书、摘要；
客户端对证书进行校验：
使用浏览器或者操作系统内置的CA根证书的公钥去解密证书；
使用相同的算法对证书进行摘要
从证书取出服务器公钥后，去解密数字签名，与先前的生成的摘要进行比较，如果相同则信任证书；
客户端用client-param、server-param使用ECDH算法算出pre-master，服务端类似算出 pre-master
用 client-random、server-random、pre-master计算出最终的会话密钥；
客户端返回握手数据的摘要；
ECDH是指通过 client-random、client-params、server-random、server-params 计算出 pre-master 的基于椭圆曲线的加密算法；
后面跟着一个E是表示临时的意思，这些私钥都是临时生成的
HTTP明文传输数据，数据传输的安全性和完整性都难以保证；
HTTPS通过SSL/TLS层对明文数据进行加密，同时验证服务端的身份，保证数据传输的安全性和完整性；
https中安全协议的流程
见上
https怎么保证安全性
使用对称加密算法加密传输的数据，使用非对称加密算法保证对称加密算法协商过程的安全性，生成会话秘钥，保证数据传输的安全性，不会被窃听；
对于发送的数据，使用摘要算法生成签名附在数据中，接收到数据后需要先解密（会话密钥解密）再用相同的摘要算法核对签名，可以保证数据传输的完整性，识别是否被篡改；
客户端使用CA机构的根证书来验证服务端的证书，用于保证服务端的身份正确，没有被伪装；
使用 CA 机构根证书中的公钥来解密服务端证书的数字签名
使用相同的摘要算法生成证书的摘要值，与上面解密得到的摘要值进行比对，如果相同则信赖；
HTTP几个版本做了什么样的改进？
HTTP/1.0：
使用短连接，即每一次HTTP事务结束后都会断开TCP连接；（每次HTTP请求都需要重新建立连接，三次握手和四次挥手，延迟较大）
请求一次后需要等待响应后，才能发送下一个请求；
HTTP/1.1
默认开启长连接，即 keep-alive，HTTP事务结束后不会断开TCP连接，后续的事务可以复用该链接（提高资源的复用，减少请求的演示）
缓存控制：相较于HTTP/1.0的Expires、If-Modified-Since缓存控制字段，增加了Entity Tag、If-Unmodified-Since、If-None-Match 的缓存控制字段；
管道化：支持请求连续发送，无需等待响应返回才能发送下一个请求；
支持range字段，HTTP/1.0 若资源部分更新则需要返回整个文件，HTTP/1.1 通过 range 资源来控制获取资源的范围；
HTTP/2
多路复用：多个HTTP事务共用一个TCP连接；
采用二进制格式：相较于之前版本的基于文本传输，HTTP/2 使用二进制传输数据，引入 “帧”，增加信息传输的利用率；
压缩头：通过客户端和服务端维护一张头部表并动态更新，减少冗余头部信息的传递；
服务端推送：允许服务端主动向客户端发送资源
HTTP/3：
主要采用UDP发送数据，基于UDP协议上层做了一些保证可靠性的操作，类似TCP的序列应答、超时重传、拥塞控制等；
解决了 HTTP/2 协议中因 TCP 协议导致的队头堵塞操作（TCP协议中如果缓冲区某个包丢失，则需要等待该包重传才能将缓冲区的内容送到应用层），UDP协议并没有这样的机制，因此不会产生队头堵塞操作；
集成了 TLS1.3；
HTTP和HTTPS的区别？对称加密和非对称加密？说一些常见网络错误码？
HTTP是明文传输数据内容，并且没有安全验证，容易在传输过程中窃取数据或者被篡改、伪装数据；
HTTPS对数据进行加密传输；
使用对称加密算法进行加密解密，但是对称加密算法的密钥在传输过程中可能被窃取，因此使用非对称加密算法保证协商过程的安全性，生成用于对称加密算法的会话秘钥；
客户端通过CA机构的证书来验证服务端的身份是否正确；
使用哈希算法对传输内容进行摘要，保证数据的完整性；
对称加密是加密和解密都是用同一个密钥进行，比如ASE；
非对称加密是有一对公钥和私钥：
公钥加密的内容只有私钥可以解密，用于加密传输数据；
私钥加密的内容只有公钥可以解密，用于验证摘要数据；
常见的网络错误码：
200：成功响应
201：身份未验证
301：永久重定向
302：临时重定向
304：资源未修改，可以使用缓存资源；
400：请求有语法错误
401：权限不足
403：服务器拒绝执行
404：请求资源不存在；
500：服务器内部错误
https相比http多了哪些步骤
HTTPS相较于 http 多了 SSL/TLS 加密层，在TCP连接建立完成之后，会进行TLS层的握手流程：
客户端使用内置CA根证书验证服务器的证书合法性；
通过密钥交换算法，产生一个用于对称加密算法的会话秘钥，对通信发送的数据进行加密；
https具体在哪一层加密的
位于 TCP 层上方的 SSL/TLS 层
HTTP发送请求时，SSL/TLS 层会负责将数据加密；
当接收HTTP响应时，SSL/TLS层负责将数据解密；
http之前不支持长连接，后来是怎么支持长连接的？
HTTP/1.0 版本是短连接，每次HTTP事务结束都会断开TCP连接；
从 HTTP/1.1 版本开始，通过 Connection: Keep-alive 头部信息可以不断开连接，保留该TCP连接复用，此时是长连接
3开头的的错误码什么意思？
表示重定向相关，表示完成请求资源需要进一步操作：
301：永久重定向
302：临时重定向；
304：资源未修改，可以使用缓存资源；
http的断点传续
http分块机制
HTTP/2头部key-value怎么编成二进制
QUIC协议如何实现的
缓存
http缓存
讲一下协商缓存
etag和last_Modified中etag怎么实现的
哈希算法有哪些？
网页输入http://baidu.com为什么会直接变成https://baidu.com(协议升级）
按照自己搭建博客的经验，在 nginx 可以配置80端口，将 http 协议的 url 重定向为 https 的 url；
也就是说是服务器将输入的网址重定向为 https://baidu.com，使其使用 https 协议进行通信；
DNS
Domain-Name-System域名系统，用于将人类可读的域名转换为对应的IP地址；
由多个分布式层次数据库的DNS服务器组成，分为根DNS服务器、顶级域DNS服务器和权威DNS服务器（一级、二级...DNS服务器），每台DNS服务器存有部分数据；
DNS原理
（回答得简单些）
主机查询域名时，如果是浏览器发起则先访问浏览器的DNS缓存，如果没有没有或者过期则会到操作系统的DNS缓存查找，还是没有则会向本地DNS服务器发起DNS请求，通过 迭代查询 和 递归查询 的方式来获取域名对应的IP地址，将查询得到的IP地址返回给主机
DNS解析过程&url网页显示过程
浏览器输入URL后：
查看浏览器缓是否有DNS缓存，如果存在则返回，否则进行一个系统调用查看本地hosts文件是否有对应的DNS缓存；
如果还是没有就会向本地DNS服务器发送DNS解析请求，本地DNS服务器通过递归查询或者迭代查询向根DNS服务器、顶级域DNS服务器等查询域名对应的IP地址；本地DNS服务器拿到解析结果后返回给查询主机，操作系统或者浏览器会对DNS结果进行缓存；
浏览器拿到对应的IP后， 向目标主机发起TCP连接请求，标志位SYN为1；服务器收到请求报文后返回一个应答报文（ACK、SYN均为1），浏览器收到后应答报文后继续发送 ACK为1的确认连接报文，此时TCP连接建立成功；
如果url使用的是 https 协议，那么还会进行 TLS 层的握手流程，验证服务器的证书，生成加密用的会话密钥；
浏览器向服务器发送GET方法的HTTP请求，其中在请求头包含了 Accept-Encoding编码信息、Cookie本地缓存信息、UA等浏览器的信息；
服务端根据接收到的HTTP请求，将对应的资源返回给浏览器，其中响应头的 Content-Type 表明了资源的类型，比如 text/html 表示资源是一个网页，浏览器根据这个字段来进行不同的渲染、执行操作；
一般来说大型网站会返回一个重定向响应，用于负载均衡，浏览器需要根据重定向的地址继续完成访问操作；
DNS解析可能出现什么问题？
DNS劫持，DNS解析需要向多个DNS服务器发送DNS请求，因为该过程是没有加密、非安全的，容易被伪造DNS响应，返回错误的IP地址；
DNS解析延迟：DNS解析需要向多个DNS服务器发送DNS请求，最终获取到IP地址会有一定的延迟；同时因为DNS服务器缓存返回的IP地址不一定是最优的；
DNS解析转发：DNS服务器可能将DNS请求转发给另一个DNS服务器进行，会返回另一个DNS服务器的IP地址，影响访问速度；
DNS解析错误：DNS服务器的缓存未过期但是IP地址已经更新，此时返回的IP地址就是错误的