网络编程

TCP/IP协议栈四层模型

• 应用层: 负责为用户提供应用功能
  • HTTP，DNS，SSH，FTP，SMTP
• 传输层: 负责进程与进程之间的通信
  • TCP，UDP
• 网络层: 负责网络包的分片，路由
  • ARP，RARP，DHCP，NAT，ICMP
• 网络接口层: 负责网络包在物理网络上的传输
  • PPP

OSI七层模型

从下往上: 物理层，数据链路层，网络层，传输层，会话层，表示层，应用层

常用协议及作用

• 应用层:

  • HTTP: 在互联网两点之间传递超文本的规范
  • DNS: 把域名解析为IP地址

• 传输层:

  • TCP: 传输控制协议
  • UDP: 用户数据报协议

• 网络层:

  • ARP: 即地址解析协议，由IP地址获取MAC地址
  • RARP: 由MAC地址，获取IP地址
  • DHCP: 动态获取IP地址
  • NAT: 实现 内网IP与外网IP 的相互转换，缓解外网IP的消耗
  • ICMP: 告知网络包传送过程中产生的错误信息

TCP 和 UDP的区别

1. TCP需要先与对方建立连接才能发送数据，而且接收方收到后必须响应，发送方收到响应后这个数据包才算传输完成，所以它安全可靠，能保证数据不丢失不重复; UDP不用事先建立连接就可以任意收发数据，传输效率高，但不能保证数据一定送达; 所以TCP一般用于网上购票，传输文件这种对稳定性要求较高的场景，而UDP一般用于实时视频会议这种对传输效率要求较高的场景
2. TCP只支持一对一; UDP支持一对一，一对多，多对多的交互通信
3. TCP报文不限制最大长度，一次发送可以分多次接收; UDP报文的最大长度为65535个字节，分几次发送就必须分几次接收，一个大报文只要丢了一个分片，整个UDP报文都会被丢弃

DNS查询的过程(域名解析)

• 浏览器查看自身缓存

• 操作系统缓存

• 本机hosts文件

• 本地域名服务器

  • 根域名服务器
  • 顶级域名服务器(com)
  • 权威域名服务器(qq.com，sports.qq.com)

• 本地域名服务器返回查到的IP给浏览器

浏览器输入url中间经历的过程

1. 浏览器从地址栏的输入中解析URL，获取web服务器的IP地址和端口号
2. 浏览器通过三次握手与web服务器建立TCP连接
3. 浏览器发送HTTP请求报文，这个报文会依次加上TCP头，IP头，MAC头，组成一个完整的数据包
4. 数据包经过网卡转换为电信号，在网线上传输，中途要经过很多交换机和路由器
5. 经过路由器时，路由器会查询路由表来确定下一跳的IP，一直转发到与目标IP同一网段的路由器
6. 这个路由器会查ARP表获取目标IP服务器的MAC地址，然后通过某个端口转发给web服务器
7. web服务器收到数据包后，会依次拆开MAC头，IP头，TCP头，然后把HTTP请求报文发给监听指定端口的服务端进程
8. 服务端进程收到请求报文后处理请求，然后发送响应报文给浏览器
9. 浏览器收到后解析响应报文，渲染输出页面

集线器，交换机，路由器的区别

1. 集线器工作在物理层，通过广播的形式转发数据，实现局域网内设备的连接，只能半双工通信
2. 交换机工作在数据链路层，通过MAC地址转发数据，实现局域网内设备的连接，是全双工通信
3. 路由器工作在网络层，通过IP地址转发数据，实现了不同网络之间的连接

TCP三次握手

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zAwg8OQk-1630134046911)(面试八股文.assets/image-20210706084255418.png)]

• 第一次握手时，客户端发送一个SYN报文给服务端，自身进入SYN_SENT状态
• 第二次握手时，服务端发送一个SYN报文给客户端，自身进入SYN_RCVD状态
• 第三次握手时，客户端发送一个ACK报文给服务端，客户端进入ESTABLISHED状态, 服务端收到后会创建一个新的TCP套接字用于和此客户端通信, 这个套接字也进入ESTABLISHED状态

(1) 为什么不能两次握手?

只有三次握手才能确保双方的发送和接收都是正常的，如果是两次握手的话，不能确保服务端发送正常，客户端接收正常，三次握手还可以防止已经失效的请求后来才传送到服务器，导致再次建立连接浪费服务器资源

(2) 如果已经建立了连接，但是客户端出现了故障怎么办?

TCP设有一个保活计时器，一般定时为2小时，如果期间收到客户端的请求就会重新开始倒计时，当服务端超过2小时未收到客户端的任何请求，服务端就会发送探测报文，没有响应就会认定客户端出现故障，从而断开连接

TCP四次挥手

• 第一次挥手: 假设是客户端先发起断开连接的请求，客户端发送一个FIN报文给服务端，自身进入FIN_WAIT_1状态
• 第二次挥手: 服务端发送一个ACK报文给客户端，自身进入CLOSE_WAIT状态, 客户端收到后进入FIN_WAIT_2状态, 在此期间服务端可以继续向客户端发送数据
• 第三次挥手: 服务端发送一个FIN报文给客户端，自身进入LAST_ACK状态
• 第四次挥手: 客户端发送一个ACK报文给服务端，自身进入TIME_WAIT状态，等待2*MSL的时间进入CLOSED状态，服务端收到ACK报文后进入CLOSED状态

(1) 为什么中间的两次挥手不合并为一次?

因为客户端想断开连接的时候，服务端如果还有数据要发给客户端，就要先发一次ACK报文，告知客户端"我知道你想断开了". 然后服务端给客户端发送数据，等数据发完服务端再发送FIN报文. 抓包时发现, 若服务端没有数据要发给客户端, 中间的两次挥手会合并为一次

(2) 为什么TIME_WAIT状态要经过2MSL才进入CLOSED状态?

如果最后一个ACK报文发出后丢失了，服务端就会再次发送FIN报文，所以客户端收到第二次FIN报文的时间最长是2MSL，此时如果客户端直接进入CLOSED状态，就无法再重发最后一个ACK报文，导致服务端无法进入CLOSED状态. 如果设置这样一个时间段，客户端在此期间没有收到FIN报文，说明服务端成功收到最后一个ACK报文

TCP如何保证可靠通信?

• 校验和: TCP头有校验和字段，检测数据传输过程中是否有差错，若有则丢弃
• 超时重传: 发送方在规定的时间内没有收到确认就要重传之前发送的报文
• 还有 流量控制 和 拥塞控制

正向代理和反向代理

正向代理: 是客户端的代理，代替客户端发起网络请求

• 可以对外隐藏客户端信息，保护用户隐私
• 可以访问客户端无法访问的资源，如国内访问谷歌需要先连接一个正向代理服务器

反向代理: 是服务端的代理，代替服务端接收网络请求

• 可以对外隐藏服务端信息，防止内网的服务器被攻击
• 可以实现负载均衡，把访问压力分散到多个服务器上

GET和POST的区别

GET用于从服务器获取数据，POST用于向服务器提交数据

GET请求是安全且幂等的，多用于查询操作

POST请求既不安全也不幂等，多用于注册操作

注: 安全指的是 请求方法不会修改服务器的资源，幂等指的是 多次请求返回的结果都相同

常用的HTTP状态码

• 1xx: 提示信息，表示现在是协议处理的中间阶段，还有后续操作
• 2xx: 成功，报文已经收到并被正确处理
  • 200: OK，请求成功
  • 204: No Content，请求成功，但响应体为空
  • 206: Partial Content， 请求成功，但响应体只有一部分数据
• 3xx: 重定向，资源位置变动
  • 301: Move Permanently，请求的资源不存在，需要用另一个URL访问
  • 302: Found，请求的资源存在，需要用另一个URL访问
  • 304: Not Modified，请求的资源未修改，让客户端自己找缓存文件
• 4xx: 客户端请求报文有误
  • 400: Bad Request，客户端请求报文有错误
  • 401: Unauthorized，客户端身份认证不通过
  • 403: Forbiden，拒绝执行客户端的请求
  • 404: Not Found，找不到客户端请求的资源
  • 405: Method Not Allowed，请求方法不被允许
• 5xx: 服务器错误
  • 500: Internal Server Error，服务器处理请求时出错
  • 501: Not Implemented，请求的功能暂不支持
  • 502: Bad Gateway，反向代理服务器出错
  • 503: Service Unavailable，服务器繁忙，无法响应

HTTP的特点(优缺点)

1. 简单灵活可扩展，报文基本格式都是 起始行+header+body
2. 可靠传输，HTTP是基于TCP协议的
3. 跨语言跨平台，不限定某种编程语言或操作系统
4. 无状态，每个请求都是互相独立的. 好处是可以通过负载均衡把请求转发到任意一台服务器，坏处是每次请求都要验证身份信息
5. 请求-应答模式，客户端主动发起请求，服务端被动回复请求，效率较低，可能会发生队头阻塞
6. 明文传输，如果连上钓鱼wifi，流量被截获保存，可能会泄漏自己的账号密码等信息
7. 不安全，无法判断报文在传输过程中是否被篡改

HTTP/1.1的特点(优缺点)

• 使用长连接，减少了频繁建立与断开连接的开销
• 可以连续发送多个请求，减少了整体的等待时间
• 如果前面的请求响应特别慢，会阻塞后面的所有请求（队头阻塞）
• 以文本格式传输header，有严重的数据冗余
• 明文传输，不安全

HTTP/2的特点

• 头部压缩
• 报文以二进制格式传输
• 支持服务端主动向客户端发送消息
• 使用数据流全双工通信，解决了队头阻塞问题
• 支持请求优先级，让服务端优先处理重要资源，优化用户体验

HTTP 与 HTTPS的区别

• HTTP是明文传输，不安全; HTTPS在传输层和应用层之间加了TLS层，使得报文能加密传输
• HTTP端口是80，HTTPS端口是443
• HTTPS在TCP三次握手后还要进行TLS握手

HTTPS是如何保证安全的?

• 混合加密，解决了窃听的问题
• 摘要算法，解决了篡改的问题
• 将服务端公钥放到数字证书中，解决了冒充的问题

HTTPS TLS握手过程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MTlyMzrG-1630134046913)(面试八股文.assets/image-20210630142543078.png)]

HTTPS，HTTP/2，WebSocket分别解决了HTTP的什么问题?

HTTPS: 加密传输，保证安全通信

HTTP/2: 解决队头阻塞

WebSocket: 不再使用“请求-应答”模式，而是全双工实时通信

什么是IO多路复用?

IO多路复用中，多路指的是有多个文件描述符fd，复用指的是用一个线程来处理。它实现了用一个线程监视多个fd，一旦有fd就绪，select, epoll这些系统调用就会返回，用户态线程就可以对这些就绪的fd进行相应的读写操作。

它的效率很高，因为它由操作系统内核帮我们找出就绪的fd，使得我们不必轮询每个fd的read()函数，从而避免了频繁切换上下文

同步 异步 阻塞 非阻塞 IO的区别?

同步IO: 调用IO函数后等待结果返回

异步IO: 调用IO函数后直接返回，等IO完成后会自动调用回调函数

阻塞IO: 在等待IO结果返回时，会主动让出CPU时间片，进入阻塞态

非阻塞IO: 在等待IO结果返回时，不断轮询直到收到结果

select，poll，epoll的区别?

• select只知道有fd就绪，但不知道具体是哪几个，需要用户自己遍历找到就绪的fd
• poll本质上和select没有区别，但是它去除了select只能监听1024个fd的限制
• epoll会直接返回已就绪的fd，但是它只能在Linux操作系统上用

python并发网络库有哪些?

• asyncio: 内置的并发网络库. 基于原生协程，只有调用await asyncio.sleep()才会切换协程，遇到其它IO操作不会切换协程
• gevent: 第三方并发网络库，基于greenlet协程，使用monkey_patch()后，遇到IO操作基本都会自动切换协程
• tornado: 既是一个并发网络库，也是web服务框架，基于IO多路复用实现的单线程并发

TCP 粘包

多个TCP数据包传输的数据内容合在了一起，没办法区分数据边界

• 发送方两次send()的时间间隔过短，TCP会用Nagle算法把它们的数据内容合在一起
• 接收方没及时用recv()接收缓冲区的包，导致多个TCP包的数据内容合在了一起

如何解决?

• 采用请求-应答模式，每次都一发一收
• 自定义消息格式: 包头 + 包体，包头是一个4字节整数，记录包体长度，每次先收4字节，读出包体长度，再收取对应字节的数据就是包体

如何理解TCP的有状态 和 HTTP的无状态

TCP有状态，是指它不同的请求之间都是有关联的，比如序号seq是递增的，而且它能够记住和它相连的主机的IP和端口

HTTP无状态，是指它不同请求之间是独立的，而且它不会记住刚刚登录的用户

HTTP状态保持

HTTP本身是无状态的，从而导致用户登录之后，下次发送请求还要携带账号密码进行身份验证

所以为了让HTTP有状态，需要额外引入一些机制，记录浏览器和服务端的会话状态

常用的方案有三种: session，cookie，token

Session和Cookie的区别

都是为了让HTTP实现状态保持

• cookie数据一般保存在浏览器缓存中，可以被篡改，不安全， 发送请求时由于要携带cookie，会消耗更多带宽
  • cookie是服务器委托浏览器存储的一些数据，一般用于保存用户名，购物车等信息
• session数据一般保存在服务器内存中，当访问量大时，服务器内存压力大
  • 当有多台服务器时，多次请求很可能落到不同的服务器上，使得状态保持失效，不利于分布式服务器进行负载均衡处理

Session，Cookie，Token的原理

• Cookie: 用户登录后，服务端委托浏览器把用户信息存储在cookie中，客户端每次发起请求时要携带这个cookie，服务端接收请求时从cookie中取出用户信息，就知道是哪个用户了. 但是服务端无法检测Cookie是否被篡改，所以不安全
• Session: 用户登录后把用户信息保存到服务器内存中，并返回一个sessionid让浏览器设置到cookie中，浏览器之后每次发起请求都携带cookie，服务端收到请求后取出cookie中的sessionid，再从内存中取出与之对应的用户信息，就知道是哪个用户了. 但是当用户增多时，服务器内存压力会很大.
• Token: 用户登录后，服务端会签发一个token发给客户端，客户端收到后把token放到cookie或LocalStorage，之后每次向服务端请求资源时都要携带token，服务端收到后验证token，就知道是哪个用户了. 服务端可以检测到token是否被篡改，比较安全

衡量服务器性能的三大指标

• 吞吐量 (requests per second): 每秒的请求次数，简称RPS 或 TPS，QPS
• 并发数 (concurrency): 服务器能同时支持的客户端数量
• 响应时间 (time per request): 服务器的处理能力

HTTP请求头字段

Host: 指定服务器的域名

Connection: 常用于要求服务端使用TCP长连接，HTTP/1.1默认是长连接，但为了兼容老版本设置此字段，一般都是Keep-Alive

Content-type: 告诉对方本次数据的格式，如image/png

Accept: 声明自己可以接受哪些数据格式，*/*代表接受任意类型

Accept-Encoding: 声明自己可以接受哪些压缩方法，如gzip，deflate

User-Agent: 描述客户端是哪个浏览器或者是爬虫

HTTP响应头字段

Content-length: 数据长度

Content-type: 告诉对方本次数据的格式，如image/png

Content-encoding: 返回的数据使用的压缩格式，如gzip

Date: 服务器的响应时间

Server: web服务器的名称和版本号