计算机网络-面试

HTTP

HTTP/HTTPS

• HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
• 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
• HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
• http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
• HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

Http请求步骤

一次完整的HTTP请求步骤
1 对www.baidu.com这个网址进行DNS域名解析，得到对应的IP地址
2 根据这个IP，找到对应的服务器，发起TCP的三次握手
3 建立TCP连接后发起HTTP请求
4 服务器响应HTTP请求，浏览器得到html代码
5 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）（先得到html代码，才能去找这些资源）
6 浏览器对页面进行渲染呈现给用户
7 服务器关闭关闭TCP连接

http

格式

请求报文：

• 请求行：请求方法，URL，版本号
  • 请求方法：
    HTTP1.0定义了三种请求方法： GET, POST ，HEAD
    HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE，CONNECT
    • GET POST?
      数据传输方式不同：GET请求通过URL传输数据，而POST的数据通过请求体传输。
      安全性不同：POST的数据因为在请求主体内，所以有一定的安全性保证，而GET的数据在URL中，通过历史记录，缓存很容易查到数据信息。
      数据类型不同：GET只允许 ASCII 字符，而POST无限制
      GET无害： 刷新、后退等浏览器操作GET请求是无害的，POST可能重复提交表单
• 请求头：
  User-Agent：产生请求的浏览器类型。
  Accept：客户端可识别的内容类型列表。
  Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机
  • 请求体
  • 空行
• 状态码
  200 - 请求成功
  301 - 资源（网页等）被永久转移到其它URL
  404 - 请求的资源（网页等）不存在
  500 - 内部服务器错误
  

2.0与1.x的区别

• 二进制分帧
• 服务器推送：在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。
• 头部压缩
• 多路复用：
  HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制。
  HTTP2中：
  同域名下所有通信都在单个连接上完成。
  单个连接可以承载任意数量的双向数据流。
  数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装
• HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？
  1. HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
  2. HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
  3. HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；具体如图：

HTTP/TCP: keepalive

keepalive

Cookie/Session

比较：

①存在的位置：
cookie 存在于客户端，临时文件夹中
session：存在于服务器的内存中，一个session域对象为一个用户浏览器服务

②安全性
cookie是以明文的方式存放在客户端的，安全性低，可以通过一个加密算法进行加密后存放
session存放于服务器的内存中，所以安全性好

③网络传输量
cookie会传递消息给服务器
session本身存放于服务器，不会有传送流量

④生命周期(以20分钟为例)
(1)cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束，
(2)session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁
但是，如果在20分钟内（如在第19分钟时）访问过session，那么，将重新计算session的生命周期
(3)关机会造成session生命周期的结束，但是对cookie没有影响

⑤访问范围
session为一个用户浏览器独享
cookie为多个用户浏览器共享

TCP/UDP

用户数据报协议 UDP（User Datagram Protocol）
是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。
UDP 常用于以下几个方面：
1.包总量较少的通信（DNS、SNMP等）；
2.视频、音频等多媒体通信（即时通信）；
3.限定于 LAN 等特定网络中的应用通信；
4.广播通信（广播、多播）。

传输控制协议 TCP（Transmission Control Protocol）
是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。

基于

TCP: 有比较高的可靠性，一些要求比较高的服务一般使用这个协议，FTP、Telnet、SMTP、HTTP、POP3
UDP: DNS, RIP(路由选择信息协议,一种在网关与主机之间交换路由选择信息的标准)

UDP实现可靠传输

实现不在传输层，实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。

1、添加seq/ack机制，确保数据发送到对端
2、添加发送和接收缓冲区，主要是用户超时重传。
3、添加超时重传机制。

三次握手/四次挥手

三次握手过程

第一次：（假设）客户端发起，发SYN=1，seq=i，进入SYN_SENT状态。
第二次：服务接受并确认，ACK=1, ack=i+1，同时发SYN=1，seq=j，进入SYN_RECV状态
第三次：客户端确认，ACK=1, ack=j+1，SYN=1，seq=i+1, 双方进入ESTABLISHED状态

如何在 Linux 系统中查看 TCP 状态？

TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看。

为什么要三次握手？

1. 防止已经失效的报文突然又传送到服务端，服务端收到报文后建立连接，并一直等待客户端响应，造成资源浪费。
2. 序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
3. 由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？
   如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

四次挥手过程

第一次：（假设）客户端发FIN=1，seq=x
第二次：服务器发ACK=1，ack=x+1，seq=m
第三次：服务器发FIN=1，ACK=1，ack=x+1，seq=n
第四次：客户端发ACK=1, ack=n+1，seq=x+1

• 为什么四次
  主要是为了在确保客户端和服务端双方不需要通信的时候，及时的断开连接，不在占用资源服务器资源。

TCP长连接，短连接

短连接：Client 向 Server 发送消息，Server 回应 Client，然后一次读写就完成了，这时候双方任何一个都可以发起 close 操作，不过一般都是 Client 先发起 close 操作。短连接一般只会在 Client/Server 间传递一次读写操作。

短连接的优点：管理起来比较简单，建立存在的连接都是有用的连接，不需要额外的控制手段。

长连接：Client 与 Server 完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

在长连接的应用场景下，Client 端一般不会主动关闭它们之间的连接，Client 与 Server 之间的连接如果一直不关闭的话，随着客户端连接越来越多，Server 压力也越来越大，这时候 Server 端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致 Server 端服务受损；如果条件再允许可以以客户端为颗粒度，限制每个客户端的最大长连接数，从而避免某个客户端连累后端的服务。

TCP拥塞控制

慢开始：指数增长，直到阈值
拥塞避免：加法增长。

• 丢包。丢包后窗口cwnd=0，阈值ssthresh/=2，进入慢开始
• 3-ACK：
  • 快恢复。阈值ssthresh=cwnd/2, 窗口cwnd=ssthresh，仍在拥塞避免
  • 快重传：立即重传

TCP粘包、拆包及解决办法

为什么粘包

• TCP是字节流
• TCP首部没有固定长度

具体情况

• 正常
  

• 粘包
  

• 粘包和拆包
  

发生原因

• 粘包
  • 待发送数据小于缓冲区大小
  • 接收方迟迟不接受
• 拆包
  • 待发送数据大于缓冲区大小
  • 待发送数据大于最大报文长度MSS

解决

在应用层解决

1. 设置消息定长
2. 设置消息分隔符
3. 分离消息头和消息体：消息头含有消息长度

滑动窗口

发送方和接收方都有一个窗口，发送方窗口大小由接收方决定，接收方通过TCP报文告诉发送方自己的窗口大小。但二者是约等关系，因为存在时延。
发送方接到ACK后窗口右移，接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。
接收窗口只对发来的最后一个按序到达的进行确认。