计算机网络–女锅补计网

99%摘抄于 wolverinn 的 github

什么是三次握手？

第一次握手：SYN = 1；seq = xxx； >>>>
第二次握手：ACK = 1；ack = xxx + 1；SYN = 1；seq = yyy； <<<<
第三次握手：···································ACK = 1；ack = yyy + 1； >>>>

• 第一次握手：SYN 置1，随机生成 seq 发送给服务端，进入 SYN_SENT状态。
• 第二次握手：收到 SYN = 1 后，知道请求连接，将 ACK 置 1 ，产生 ack = seq + 1，SYN 置 1，随机生成 seq 发给客户端，进入 SEND_RCVD 状态。
• 第三次握手：检查发来的 ACK 和 ack，将 ACK 置 1 ，产生 ack = 服务端 seq + 1，进入 ESTABLISHED 阶段。
  服务器检查 ACK 和 ack 后，也进入 ESTABLISHED 阶段。完成三次握手，连接确立。

为什么要三次握手？

要确定双方的发送接收能力，第一次握手服务端知道客户端的发送和自身的接收 OK；第二次握手客户端知道自身的发接 OK，服务端的接发 OK；第三次握手服务端知道自身接发 OK，客户端接发 OK。

为什么不能两次握手？

1. 服务端无法知道自身的发送和客户端的接收是否 OK。
2. 无法保证双方成功互换序列号。
3. 可能出现已失效的连接请求报文又发送到了服务端，服务端误以为客户端请求新的连接，发送了确认报文同意连接。若为两次握手，连接已建立，但客户端并不理睬，服务端一直等待，浪费服务端资源。若三次握手，服务端将收不到第三次握手，则不会建立连接。

可以四次握手吗？

可以，但会降低传输效率。

四次握手是将第二次握手拆分开来，先发 ACK 和 ack，再发 SYN 和 seq。没什么必要，出于优化目的，可合并。

第三次握手中，若 ACK 未到达服务端，会怎样？

• 服务端：重发之前的 SYN 和 ACK（默认重发五次，之后自动关闭连接进入CLOSED状态）。
• 客户端：收到服务端的重发后会重传 ACK。如果服务端已经 CLOSED，会收到 RST 包应答。

如果建立连接后，客户端出现了故障会怎样？

服务器每次收到一个客户端请求后，都会重新复位一个定时器，一般是计时 2 小时，若两小时内没收到客户端数据，则会每隔75秒发送一个探测报文段，若10次后依然没收到回复，则认为客户端出现故障，关闭连接。

初始序列号是什么？

TCP 连接的一方，随机生成一个 32 位的 Sequence Nubmer，作为发送数据的初始序列号，并以次序号为原点，对要传输的数据进行编号。在三次握手时，双方交换初始序列号，以便传输时可以确认对方的什么编号是合法的，并确认收到的每一个字节。

什么是四次挥手？

第一次挥手手：FIN = 1；seq = xxx >>>>
第二次挥手：ACK = 1；ack = xxx + 1； <<<<
第三次挥手: ···································FIN = 1；seq = yyy； <<<<
第四次挥手：·································ACK = 1；ack = yyy + 1； >>>>

• 第一次挥手：FIN_WAIT_1。
• 第二次挥手：FIN_WAIT_2 — CLOSE_WAIT。此时客户端不发数据了，但仍可接收服务端数据。
• 第三次挥手：··························· LAST_ACK。
• 第四次挥手：TIME_WAIT — CLOSED。客户端等待 2*MSL （报文段最大存活时间）时间后，也进入CLOSED状态。完成四次挥手。

为什么不是三次？

因为服务器收到断开请求后，可能还有数据没有发完，则先回复 ACK 告诉客户端我收到了你的断开请求，
等数据传输完后，发送 FIN，表示可以断开了。

第二次挥手客户端没收到 ACK 会怎样？

客户端会重新发送 FIN。

客户端 TIME_WAIT 的意义？

第四次挥手时，主动关闭方发送的 ACK 可能丢失，TIME_WAIT 状态用来重发 ACK 报文。如果被动关闭方没收到 ACK，会立即重发 FIN，主动方如果在 2*MSL 内收到 FIN，则重发 ACK 并再次等待 2*MSL。若 2MSL 过后，客户端没有再收到 FIN，则客户端推断服务端已经收到 ACK，则结束 TCP 连接。若没有这个状态，主动方第二次收到 FIN 时，会响应一个 RST，被解释成一种错误。

TCP 如何实现流量控制？

使用滑窗协议实现流量控制，为了防止发送方发送速率太快，接收方缓存区不够导致溢出，接收方会根据自己的资源情况动态维护一个接收窗口。在返回确认报文时将接收窗口的大小放在 TCP 报文的窗口字段告知发送方。 发送方窗口大小不能大于接收方。只有当发送方发送并收到确认后，才可将发送窗口右移。

什么是零窗口？

当接收方没有能力接收新数据时，会将接收窗口设置为0。这时发送方必须停止发送数据，但会启动一个持续计时器，到期后发送一个大小为 1 字节的探测数据包，以查看接收窗口动态。若接收方能接收数据，则在返回报文中更新窗口大小，恢复传输。

TCP 如何实现拥塞控制？

• 慢启动；拥塞避免；快重传；快恢复；
  

• 慢启动：刚开始发送数据时，先把拥塞窗口设为一个最大报文段 MMS 的值，每收到一个确认报文时，就将拥塞窗口加 1MMS，这样每经过一个传输轮次，拥塞窗口就会加倍。

• 拥塞避免：当拥塞窗口大小到达慢启动门限时，开始执行拥塞避免算法。不再指数增加，而思线性增加，每次只加 1MMS。
  拥塞后，将慢启动门限减为当前值的一半，并将拥塞窗口大小设置为 1 重新开始一轮慢启动。

• 快重传：要求当接收方收到每个报文后立即发送确认，而不要等到自己发送数据时捎带确认。当收到失序报文时，立即发送已收到报文的重复确认，发送方一旦连续接到三个重复确认，就将相应报文立即重传，不用等待重传计时器到期。防止因为个别报文丢失，误认为出现拥塞（将拥塞窗口置为 1），降低网络吞吐量。

• 快恢复：发送方连续收到三个重复确认，知道只是丢失个别报文，于是不执行慢启动而是快恢复算法。
  将慢开始门限和拥塞窗口值设为当前窗口的一半，开始执行拥塞避免算法。

TCP 与 UDP的区别？

面向连接 — 无连接（不需要建立连接）
可靠的 — 不可靠的（收到报文不确认）
有流量控制 — 无流量控制
有拥塞控制 — 无拥塞控制（拥塞不会使发送速率降低）
面向字节流 — 面向报文流
点对点通信 — 都行
首部开销（20 字节） — （8 字节）

什么时候选择 TCP 或 UDP？

对实时性要求较高的使用 UDP，比如视频直播和游戏，即使出现传输错误也可以容忍；其他时候大多使用 TCP，因为需要传输的内容可靠，不出现丢失。

HTTP 可以使用 UDP 吗？

不可以，因为 HTTP需要基于可靠的传输协议，UDP 不可靠。

面向连接和无连接的区别？

无连接的网络服务（数据报服务） — 面向连接的网络服务（虚电路服务）

虚电路服务：需首先建立从源路由器到目标路由器的连接（VC），所有的数据包经过相同路径，对服务质量有保证。

数据报服务：不需要建立连接，每个数据包含目的地址，数据路由相互独立。不保证服务质量。

TCP 如何保证传输可靠性？

• 数据包校验
• 失序重排
• 重复丢弃
• 应答机制
• 超时重发
• 拥塞控制
• 流量控制

HTTP 和 HTTPS 的区别？

1. 端口不同，80 / 443
2. HTTP 是明文传输，HTTPS 运行在 SSL 上，添加了加密和认证机制，更加安全。
3. HTTPS 由于加密解密需要更大的 CPU 和内存开销。
4. HTTPS 通信需要证书，要向 CA 购买。

HTTPS 的连接过程

1. 客户端向服务器发送请求，同时发送客户端支持的一套加密规则（包括对称加密、非对称加密、Hash 算法）。
2. 服务器从中选出一组加密算法与 Hash 算法，并将自己的身份信息以证书的形式发回给客户端。证书里面包含了网站地址，公钥，以及证书的颁发机构等信息。
3. 客户端验证服务器的合法性，包括：证书是否过期，CA是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。
4. 如果证书受信任，客户端会生成一个随机对称密钥，并用服务器提供的公钥加密；使用 Hash算法对握手消息进行摘要计算，并对摘要使用之前产生的对称密钥加密；将加密后的随机密钥和摘要一起发送给服务器。
5. 服务器使用自己的私钥解密，得到对称密钥，用这个密钥解密出 Hash 摘要值，并验证握手消息是否一致。如果一致，服务器使用对称密钥加密握手消息发给浏览器；浏览器解密并验证摘要，若一致，则握手结束。之后的数据传送都使用对称密钥进行加密。

怎么确定用 HTTP 还是 HTTPS？

一种是原始的 302 跳转，服务器把所有的 HTTP 流量跳转到 HTTPS。但这样有一个漏洞，就是中间人可能在第一次访问站点的时候就劫持。
解决方法是引入 HSTS 机制，用户浏览器在访问站点的时候强制使用 HTTPS。

HTTPS 连接时，怎么确定收到的包是服务器发来的（中间人攻击）？

SSL中间人攻击：攻击者设置为客户端和服务端的中间人，伪造服务器的证书，将服务器的公钥替换成自己的公钥，之后将 HTTPS 范文替换为 HTTP返回给浏览器，而中间人和服务器之间仍然保持HTTPS连接。但是对于客户端来说，如果中间人伪造了证书，在校验证书过程中会提示证书错误，由用户选择继续操作还是返回。

对称加密与非对称加密的区别？

• 对称加密：加密解密需要相同密钥。加密速度快，一般用于大量数据加密。
• 非对称加密：公钥和私钥，一方加密一方解密，公钥任意对外发布，私钥自我保管。公钥无法推出私钥。

数字签名，报文摘要的原理

• 报文摘要：通过 Hash 算法，将发送的报文生成一个非常小的摘要信息。这个摘要信息保证报文完整性。
  只要报文有一位被篡改，则摘要信息无法匹配。
• 数字签名：先用 Hash 生成摘要后，使用私钥对摘要进行加密，生成“数字签名”。接收方使用公钥对数字签名进行解密，成功则证实是从对方发过来的。之后对收到的报文使用 Hash 生成摘要，与解密后的摘要进行对比，一致则证明报文未被修改过。
  • 认证发送方
  • 发送方不可抵赖
  • 接收方不可伪造

GET 和 POST 的区别？

1. GET 是幂等的，即读取同一个资源，总是得到相同的数据，POST 不是幂等的。
2. GET 是从服务器获取资源，POST 是向服务器传送数据。
3. 请求形式上：GET 请求的数据附在 URL 之后，在 HTTP 请求头中；POST 请求的数据在请求体（body）中。
4. 安全性：GET 请求可被缓存、收藏、保留到历史记录，且其请求数据明文出现在 URL 中。POST的参数不会被保存，安全性相对较高。
5. GET 只允许 ASCII 字符，POST 对数据类型没有要求，也允许二进制数据。
6. GET 的长度有限制（操作系统或者浏览器），而 POST 数据大小无限制。

Session 和 Cookie 的区别？

• Session：是服务端保持状态的方案，用来跟踪用户的状态，
• Cookie：是客户端保持状态的方案，用来保存一些用户信息，也是实现 Session 的一种方式。
  保存Sessionid的方式可以采用Cookie，如果禁用了Cookie，可以使用URL重写机制（把会话ID保存在URL中）。

从输入网址到获得页面的过程

详见 sky 老兄的详解

HTTP请求有哪些常见状态码？

• 2XX 成功：200 OK；
• 3XX 重定向：301 永久重定向；302 临时重定向；
• 4XX 客户端错误：400 请求报文语法错；401 有未认证信息；403 请求被服务端拒了；404 服务器无请求的资源
• 5XX 服务端错误：500 服务器内部错误；503 服务器暂时无法处理；

RIP 距离矢量路由协议

每个路由器维护一张表，表中给出了当前已知的到每个目的地的最佳距离，以及首选线路，并通过与相邻路由器交换距离信息来更新表。

网络体系结构

• 应用层：常见协议：
  • FTP 21：文件传输协议
  • SSH 22：远程登陆
  • TELNET 23：远程登录
  • SMTP 25：发送邮件
  • POP3 110：接收邮件
  • HTTP 80：超文本传输协议
  • DNS 53（UDP 的）：域名解析服务
• 传输层：TCP/UDP
• 网络层：IP，ARP（地址解析协议），NAT（网络地址转换），ICMP（报告意外）

路由器和交换机

路由器在网络层，根据 IP 地址寻址。
交换机在数据链路层，根据 MAC 地址寻址。

子网划分

从主机号host-id借用若干个比特作为子网号subnet-id；子网掩码：网络号和子网号都为1，主机号为0；数据报仍然先按照网络号找到目的网络，发送到路由器，路由器再按照网络号和子网号找到目的子网：将子网掩码与目标地址逐比特与操作，若结果为某个子网的网络地址，则送到该子网。

ARP

ARP协议完成了IP地址与物理地址的映射。每一个主机都设有一个 ARP 高速缓存，里面有所在的局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。当源主机要发送数据包到目的主机时，会先检查自己的ARP高速缓存中有没有目的主机的MAC地址，如果有，就直接将数据包发到这个MAC地址，如果没有，就向所在的局域网发起一个ARP请求的广播包（在发送自己的 ARP 请求时，同时会带上自己的 IP 地址到硬件地址的映射），收到请求的主机检查自己的IP地址和目的主机的IP地址是否一致，如果一致，则先保存源主机的映射到自己的ARP缓存，然后给源主机发送一个ARP响应数据包。源主机收到响应数据包之后，先添加目的主机的IP地址与MAC地址的映射，再进行数据传送。如果源主机一直没有收到响应，表示ARP查询失败。

NAT（网络地址转换）

用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址，分为静态转换（转换得到的全球IP地址固定不变）和动态NAT转换。