【面向校招】计算机网络全总结
0. 什么是网络协议，为什么要对网络协议分层 ?
网络协议是计算机在通信过程中要遵循的一些约定好的规则。
网络分层的原因：
-
- 易于实现和维护，因为各层之间是独立的，层与层之间不会收到影响。
- 有利于标准化的制定
1. 说说 HTTP 常用的状态码及其含义？
思路: 这道面试题主要考察候选人，是否掌握 HTTP 状态码这个基础知识点。
不管是不是面试需要，我们都要知道，日常开发中的这几个状态码的含义哈：
2. HTTP 常用的请求方式，区别和用途？
思路: 这道题主要考察候选人，是否掌握HTTP 请求方式这个基础知识点，我们用得比较多就是GET 和 POST啦。
3. 请简单说一下你了解的端口及对应的服务？
4. 说下计算机网络体系结构
思路: 这道题主要考察候选人，计算机网络体系结构这个基础知识点。计算机网路体系结构呢，有三层：ISO 七层模型、TCP/IP 四层模型、五层体系结构。大家可以记住这个图，如下
计算机网络体系结构
4.1 ISO 七层模型
ISO 七层模型是国际标准化组织（International Organization for Standardization）制定的一个用于计算机或通信系统间互联的标准体系。OSI七层模型详解
- 应用层：网络服务与最终用户的一个接口，常见的协议有：HTTP FTP SMTP SNMP DNS.
- 表示层：数据的表示、安全、压缩。，确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
- 会话层：建立、管理、终止会话, 对应主机进程，指本地主机与远程主机正在进行的会话.
- 传输层：定义传输数据的协议端口号，以及流控和差错校验, 协议有TCP UDP.
- 网络层：进行逻辑地址寻址，实现不同网络之间的路径选择, 协议有ICMP IGMP IP 等.
- 数据链路层：在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路。
- 物理层：建立、维护、断开物理连接。
4.2 TCP/IP 四层模型
★
- 应用层：对应于 OSI 参考模型的（应用层、表示层、会话层）。
- 传输层: 对应 OSI 的传输层，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。
- 网际层：对应于 OSI 参考模型的网络层，主要解决主机到主机的通信问题。
- 网络接口层：与 OSI 参考模型的数据链路层、物理层对应。
4.3 五层体系结构
★
- 应用层：对应于 OSI 参考模型的（应用层、表示层、会话层）。
- 传输层：对应 OSI 参考模型的的传输层
- 网络层：对应 OSI 参考模型的的网络层
- 数据链路层：对应 OSI 参考模型的的数据链路层
- 物理层：对应 OSI 参考模型的的物理层。
5 如何理解 HTTP 协议是无状态的
思路: 这道题主要考察候选人，是否理解 Http 协议，它为什么是无状态的呢？如何使它有状态呢？
如何理解无状态这个词呢？
HTTP的无状态，指协议对于事务处理没有记忆能力，不对通信状态进行保存，服务器无法判断用户身份。即打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。服务器不会去记住你是谁，所以是无状态协议。
可以通过一个生活中的例子，来更好理解并记住它：
有状态场景：
- 小红：今天吃啥子？
- 小明：罗非鱼~
- 小红：味道怎么样呀？
- 小明：还不错，好香。
无状态的场景：
- 小红：今天吃啥子？
- 小明：罗非鱼~
- 小红：味道怎么样呀？
- 小明：？啊？你说啥？什么鬼？什么味道怎么样？
Http 加了 Cookie 的话：
- 小红：今天吃啥子？
- 小明：罗非鱼~
- 小红：你今天吃的罗非鱼，味道怎么样呀？
- 小明：还不错，好香。
6. 从浏览器地址栏输入 url 到显示主页的过程
思路: 这道题主要考察的知识点是 HTTP 的请求过程，DNS 解析，TCP 三次握手，四次挥手这几个要点，我们都可以讲下。
- DNS 解析，查找域名对应的 IP 地址。
- 与服务器通过三次握手，建立 TCP 连接
- 向服务器发送 HTTP 请求
- 服务器处理请求，返回网页内容
- 浏览器解析并渲染页面
- TCP 四次挥手，连接结束
7. 说下 HTTP/1.0，1.1，2.0 的区别
思路: 这道题主要考察的知识点是 HTTP 几个版本的区别，我们记住HTTP/1.0默认是短连接，可以强制开启，HTTP/1.1 默认长连接，HTTP/2.0 采用多路复用就差不多啦。
HTTP/1.0
- 默认使用短连接，每次请求都需要建立 TCP 连接。服务完成立即断开，开销大；
- 错误状态响应码少；
- 不支持断点续传。它可以设置
Connection: keep-alive这个字段，强制开启长连接。
HTTP/1.1
- 默认长连接，即 TCP 连接默认不关闭，可以被多个请求复用。
- 分块传输编码，即服务端每产生一块数据，就发送一块，用” 流模式” 取代” 缓存模式”。
- 管道机制，即在同一个 TCP 连接里面，客户端可以同时发送多个请求。
HTTP/2.0
- 二进制协议，1.1 版本的头信息是文本（ASCII 编码），数据体可以是文本或者二进制；2.0 中，头信息和数据体都是二进制，实现方便，健壮性更好。
- 完全多路复用，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。
- 报头压缩：HTTP 协议不带有状态，每次请求都必须附上所有信息。Http/2.0 引入了头信息压缩机制，使用 gzip 或 compress 压缩后再发送，同时通信的双方各自缓存一份header fields表，避免了header的重复传输。
- 服务端推送：允许服务器未经请求，主动向客户端发送资源。
7.1 长连接和短连接？
HTTP协议的长连接和短连接，实质上就是TCP协议的长连接和短连接。
HTTP/1.0默认使用短连接，即Client和Server每进行一次HTTP操作，就建立一次连接，任务结束就中断。
HTTP/1.1起默认使用长连接，网页打开后，Client和Server间传输数据的TCP连接不会关闭，之后再进行访问就直接用已建立的连接。
8. POST 和 GET 有哪些区别？
思路: 这道题主要考察的知识点是 POST 和 GET 的区别，可以从数据包、编码方式、请求参数、收藏为书签、历史记录、安全性等几方面去回答哈。
9. 在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？
这个问题记住keep-alive就好，也就是说，在 HTTP 中响应体的Connection字段指定为keep-alive即可
10. HTTP 如何实现长连接？在什么时候会超时？
思路: 这道题实际上是考察 TCP 长连接的知识点，HTTP 的长连接实质是指 TCP 的长连接。至于什么时候超时，我们记住这几个参数如tcp_keepalive_time、tcp_keepalive_probes就好啦
什么是 HTTP 的长连接？
- HTTP 分为长连接和短连接，本质上说的是 TCP 的长短连接。TCP 连接是一个双向的通道，它是可以保持一段时间不关闭的，因此 TCP 连接才具有真正的长连接和短连接这一说法哈。
- TCP 长连接可以复用一个 TCP 连接，来发起多次的 HTTP 请求，这样就可以减少资源消耗，比如一次请求 HTML，如果是短连接的话，可能还需要请求后续的 JS/CSS。
如何设置长连接？
通过在头部（请求和响应头）设置Connection字段指定为keep-alive，HTTP/1.0 协议支持，但是是默认关闭的，从 HTTP/1.1 以后，连接默认都是长连接。
在什么时候会超时呢？
- HTTP 一般会有 httpd 守护进程，里面可以设置keep-alive timeout，当 tcp 连接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间
- TCP 的keep-alive包含三个参数，支持在系统内核的 net.ipv4 里面设置；当 TCP 连接之后，闲置了tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了tcp_keepalive_probes，就会丢弃该连接。
1. tcp_keepalive_intvl = 15 2. tcp_keepalive_probes = 5 3. tcp_keepalive_time = 1800
11. HTTP 与 HTTPS 的区别
思路: 这道题实际上考察的知识点是 HTTP 与 HTTPS 的区别，这个知识点非常重要，可以从安全性、数据是否加密、默认端口等这几个方面去回答哈。其实，当你理解 HTTPS 的整个流程，就可以很好回答这个问题啦。
我的答案如下：
HTTP，即超文本传输协议，是一个基于 TCP/IP 通信协议来传递明文数据的协议。HTTP 会存在这几个问题：
- 请求信息是明文传输，容易被窃听截取。
- 没有验证对方身份，存在被冒充的风险
- 数据的完整性未校验，容易被中间人篡改
为了解决 Http 存在的问题，Https 出现啦。
Https 是什么？
HTTPS= HTTP+SSL/TLS，可以理解 Https 是身披 SSL(Secure Socket Layer，安全套接层) 的 HTTP。
它们主要区别如下：
12 . Https 流程是怎样的？
思路: 这道题实际上考察的知识点是 HTTPS 的工作流程，大家需要回答这几个要点，公私钥、数字证书、加密、对称加密、非对称加密。
- HTTPS = HTTP + SSL/TLS，也就是用 SSL/TLS 对数据进行加密和解密，Http 进行传输。
- SSL，即 Secure Sockets Layer（安全套接层协议），是网络通信提供安全及数据完整性的一种安全协议。
- TLS，即 Transport Layer Security(安全传输层协议)，它是 SSL3.0 的后续版本。
Https 工作流程
- 客户端发起 Https 请求，连接到服务器的 443 端口。
- 服务器必须要有一套数字证书（证书内容有公钥、证书颁发机构、失效日期等）。
- 服务器将自己的数字证书发送给客户端（公钥在证书里面，私钥由服务器持有）。
- 客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密。
- 客户端将公钥加密后的密钥发送到服务器。
- 服务器接收到客户端发来的密文密钥之后，用自己之前保留的私钥对其进行非对称解密，解密之后就得到客户端的密钥，然后用客户端密钥对返回数据进行对称加密，酱紫传输的数据都是密文啦。
- 服务器将加密后的密文返回到客户端。
- 客户端收到后，用自己的密钥对其进行对称解密，得到服务器返回的数据。
12.1 SSL安全套接字层协议作用？
作用是建立安全连接，能和多个应用层协议协和使用保证安全传输。
- 记录协议：接收消息并处理，然后将处理过的消息继续传递。包括加解密、解压缩、分段重组等。
- 握手协议：建立在三次握手之后，为建立安全连接提供参数并进行双方的真实性认证。
- 警告协议：规定可能出现的错误等级和应对方式。
- 密码规范改变协议：在握手结束前发送，通知对方在之后的消息中使用商量好的加密算法。
13. 说说 HTTP 的状态码？301 和 302 的区别？
粗略地分：
1xx：临时响应/请求正在处理；
2xx：成功
3xx：重定向
4xx：请求错误
5xx：服务器错误。
常见的状态码有：
200：成功。
302：临时重定向到指定网页。
304：not modified服务器允许访问资源，但请求未满足条件。
400：bad request，请求报文存在语法错误。
401：unauthorized未授权，要求身份验证。
403：forbidden禁止，服务器拒绝访问。
404：not found未找到，服务器找不到请求的网页。
405：方法禁用，Post当成Get。
502：服务器网关错误。
503：service unavailable，服务器超负荷或停机维护。
504：网关超时，nginx请求超时。
302 和 301 都有重定向的含义，区别：
- 301：（永久性转移）请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。
- 302：（暂时性转移）服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。
网上有个很形象的例子比喻：
当一个网站或者网页 24—48 小时内临时移动到一个新的位置，这时候就要进行 302 跳转，打个比方说，我有一套房子，但是最近走亲戚去亲戚家住了，过两天我还回来的。而使用 301 跳转的场景就是之前的网站因为某种原因需要移除掉，然后要到新的地址访问，是永久性的，就比如你的那套房子其实是租的，现在租期到了，你又在另一个地方找到了房子，之前租的房子不住了。
14. 说说什么是数字签名？什么是数字证书？
思路: 这道题考查的知识点，不仅仅是数字签名，数字证书，很可能面试官也会问你 https 的原理的，因为 https 原理跟数字证书有关的哈，大家需要掌握 https 原理哦。
数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。它的出现，是为了避免身份被篡改冒充的。比如 Https 的数字证书，就是为了避免公钥被中间人冒充篡改：
数字证书构成
- 公钥和个人等信息，经过 Hash 摘要算法加密，形成消息摘要；将消息摘要拿到拥有公信力的认证中心（CA），用它的私钥对消息摘要加密，形成数字签名。
- 公钥和个人信息、数字签名共同构成数字证书。
15. 对称加密与非对称加密有什么区别
思路: 这道题考察的知识点是对称加密与非对称加密算法，什么是对称加密，什么是非对称加密呢？
对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有：DES、AES 等。
对称加密
非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有 RSA。
非对称加密
16. 说说 DNS 的解析过程？
思路: 这道题考察的知识点是DNS 域名解析，http 请求的过程，是涉及到 DNS 域名解析的，这道面试题也挺经典的，大家可以看下《图解 HTTP》那本书哈。
DNS，英文全称是domain name system，域名解析系统，是 Internet 上作为域名和 IP 相互映射的一个分布式数据库。它的作用很明确，就是可以根据域名查出对应的 IP 地址。在浏览器缓存、本地 DNS 服务器、根域名服务器都是怎么查找的，大家回答的时候都可以说下哈。
DNS 的解析过程如下图：
DNS 解析查找过程
假设你要查询www.baidu.com的 IP 地址:
- 首先会查找浏览器的缓存, 看看是否能找到www.baidu.com对应的 IP 地址，找到就直接返回；否则进行下一步。
- 将请求发往给本地 DNS 服务器，如果查找到也直接返回，否则继续进行下一步；
- 本地 DNS 服务器向根域名服务器发送请求，根域名服务器返回负责
.com的顶级域名服务器的 IP 地址的列表。 - 本地 DNS 服务器再向其中一个负责
.com的顶级域名服务器发送一个请求，返回负责.baidu的权威域名服务器的 IP 地址列表。 - 本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，返回www.baidu.com所对应的 IP 地址。
17. 什么是 CSRF 攻击，如何避免
思路: 这道题考察的知识点是CSRF 攻击，它是属于网络安全这块的知识点，还有Xss 攻击、SQL 注入、DDoS等这些常见的网络攻击，我们都需要知道攻击的流程哈。
什么是 CSRF 攻击？
★
CSRF，跨站请求伪造（英文全称是 Cross-site request forgery），是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。
CSRF 是如何攻击的呢？
来看一个来自百度百科的例子哈：
- Tom 登陆银行，没有退出，浏览器包含了 Tom 在银行的身份认证信息。
- 黑客 Jerry 将伪造的转账请求，包含在在帖子
- Tom 在银行网站保持登陆的情况下，浏览帖子
- 将伪造的转账请求连同身份认证信息，发送到银行网站
- 银行网站看到身份认证信息，以为就是 Tom 的合法操作，最后造成 Tom 资金损失。
怎么解决 CSRF 攻击呢？
- 检查 Referer 字段。
- 添加校验 token。
18. 聊聊五层计算机网络体系结构中，每一层对应的网络协议有哪些？
为了大家方便记忆，画了个思维导图，如下：
19. 说说 WebSocket 与 socket 的区别
思路: 这是一个比较基础的知识点，经常有小伙伴会搞混。
- Socket 其实就是等于IP 地址 + 端口 + 协议。
★
具体来说，Socket 是一套标准，它完成了对 TCP/IP 的高度封装，屏蔽网络细节，以方便开发者更好地进行网络编程。
- WebSocket 是一个持久化的协议，它是伴随 H5 而出的协议，用来解决http 不支持持久化连接的问题。
- Socket 一个是网编编程的标准接口，而 WebSocket 则是应用层通信协议。
20. 什么是 DoS、DDoS、DRDoS 攻击？
思路: 这是涉及网络安全的一个知识点，DDos 还会挺常见的，如 SYN Flood。
★
- DOS: (Denial of Service), 翻译过来就是拒绝服务, 一切能引起 DOS 行为的攻击都被称为 DOS 攻击。最常见的 DoS 攻击就有计算机网络宽带攻击、连通性攻击。
- DDoS: (Distributed Denial of Service), 翻译过来是分布式拒绝服务。是指处于不同位置的多个攻击者同时向一个或几个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。常见的 DDos 有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
- DRDoS: (Distributed Reflection Denial of Service)，中文是分布式反射拒绝服务，该方式靠的是发送大量带有被害者 IP 地址的数据包给攻击主机，然后攻击主机对 IP 地址源做出大量回应，从而形成拒绝服务攻击。
21. 什么是 XSS 攻击，如何避免?
思路: XSS 攻击也是比较常见，XSS，叫跨站脚本攻击（Cross-Site Scripting），因为会与层叠样式表 (Cascading Style Sheets, CSS) 的缩写混淆，因此有人将跨站脚本攻击缩写为 XSS。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意攻击用户的特殊目的。XSS 攻击一般分三种类型：存储型 、反射型 、DOM 型 XSS
21.1 XSS 是如何攻击的呢？
拿反射型举个例子吧，流程图如下：
21.2 如何解决 XSS 攻击问题？
- 对输入进行过滤，过滤标签等，只允许合法值。
- HTML 转义
- 对于链接跳转，如
等，要校验内容，禁止以 script 开头的非法链接。 - 限制输入长度
22. Http 请求的过程与原理
思路: HTTP 请求，一个非常非常基础的知识点，一定需要掌握的。其实觉得跟浏览器地址栏输入 url 到显示主页这道题有点类似。
我的答案如下：
HTTP 是一个基于 TCP/IP 协议来传递数据的超文本传输协议，传输的数据类型有 HTML, 图片等。以访问百度有例子，看下一次 Http 的请求过程吧
Http 请求过程
- 客户端进行 DNS 域名解析，得到对应的 IP 地址
- 根据这个 IP，找到对应的服务器建立连接（三次握手）
- 建立 TCP 连接后发起 HTTP 请求（一个完整的 http 请求报文）
- 服务器响应 HTTP 请求，客户端得到 html 代码
- 客户端解析 html 代码，用 html 代码中的资源 (如 js,css, 图片等等) 渲染页面。
- 服务器关闭 TCP 连接（四次挥手）
23. forward 和 redirect 的区别？
思路: 这道题有点偏 Java web 方向的。以前记得刚出来实习找工作的时候，面试官可喜欢问这道题啦，当时我记的答案就是，forward 是转发，redirect 是重定向。
我的答案如下：
★
- 直接转发方式（Forward） ，客户端和浏览器只发出一次请求，Servlet、HTML、JSP 或其它信息资源，由第二个信息资源响应该请求，在请求对象 request 中，保存的对象对于每个信息资源是共享的。
- 间接转发方式（Redirect） 实际是两次 HTTP 请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。
举个通俗的例子：
★
- 直接转发就相当于：“A 找 B 借钱，B 说没有，B 去找 C 借，借到借不到都会把消息传递给 A”；
- 间接转发就相当于：“A 找 B 借钱，B 说没有，让 A 去找 C 借”。**
看下这两个图，可以更容易理解一些:
- Redirect 的工作原理：
- forward 的工作原理
24. 聊聊 SQL 注入？
思路: SQL 注入是最经典的安全问题。无论你是前端开发还是后端开发，都必须掌握的。
★ SQL 注入是一种代码注入技术，一般被应用于攻击 web 应用程序。它通过在 web 应用接口传入一些特殊参数字符，来欺骗应用服务器，执行恶意的 SQL 命令，以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最常用手段之一。
24.1 SQL 注入是如何攻击的？
举个常见的业务场景：在 web 表单搜索框输入员工名字，然后后台查询出对应名字的员工。
这种场景下，一般都是前端页面, 把一个名字参数 name 传到后台，然后后台通过 SQL 把结果查询出来
name = "田螺"; // 前端传过来的
// 根据前端传过来的 name 参数，查询数据库员工表 staff
SQL= "select * from staff where name=" + name;
因为 SQL 是直接拼接的，如果我们完全信任前端传的参数的话。假如前端传这么一个参数时''or'1'='1'，SQL 就变成酱紫的啦。
select * from staff where name=''or'1'='1';
这个 SQL 会把所有的员工信息全都查出来了，酱紫就请求用户已经越权啦。请求者可以获取所有员工的信息，信息已经暴露了啦。
24.2 如何预防 SQL 注入问题
1). 使用 #{} 而不是 ${}
在 MyBatis 中, 使用**#{}**而不是**${}**，可以很大程度防止 sql 注入。
- 因为
**#{}**是一个参数占位符，对于字符串类型，会自动加上 “”，其他类型不加。由于 Mybatis 采用预编译，其后的参数不会再进行 SQL 编译，所以一定程度上防止 SQL 注入。 **${}**是一个简单的字符串替换，字符串是什么，就会解析成什么，存在 SQL 注入风险
2). 不要暴露一些不必要的日志或者安全信息，比如避免直接响应一些 sql 异常信息。
如果 SQL 发生异常了，不要把这些信息暴露响应给用户，可以自定义异常进行响应
3). 不相信任何外部输入参数，过滤参数中含有的一些数据库关键词关键词
可以加个参数校验过滤的方法，过滤union，or等数据库关键词
4). 适当的权限控制
在你查询信息时，先校验下当前用户是否有这个权限。比如说，实现代码的时候，可以让用户多传一个企业 Id 什么的，或者获取当前用户的 session 信息等，在查询前，先校验一下当前用户是否是这个企业下的等等，是的话才有这个查询员工的权限。
25. Session 和 Cookie 的区别
我们先来看 Session 和 Cookie 的概念吧：
- Cookie 是保存在客户端的一小块文本串的数据。客户端向服务器发起请求时，服务端会向客户端发送一个 Cookie，客户端就把 Cookie 保存起来。在客户端下次向同一服务器再发起请求时，Cookie 被携带发送到服务器。服务器就是根据这个 Cookie 来确认身份的。
- session 指的就是服务器和客户端一次会话的过程。Session 利用 Cookie 进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建了一个 Cookie，当这个 Session 结束时，其实就是意味着这个 Cookie 就过期了。Session 对象存储着特定用户会话所需的属性及配置信息。
Session 和 Cookie 的区别主要有这些：
来看个图吧：
- 用户第一次请求服务器时，服务器根据用户提交的信息，创建对应的 Session，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入 Cookie 中，同时 Cookie 记录此 SessionID 是属于哪个域名。
- 当用户第二次访问服务器时，请求会自动判断此域名下是否存在 Cookie 信息，如果存在，则自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到，说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
25.1 如何保持会话状态
- Cookie和Session保存会话状态，用Session来唯一标识用户，用Cookie当作用户通行证。
流程：
-
- 服务端收到请求处理后生成一个SessionId，将SessionId存入Cookie返回给客户端，将Session内容存储在服务器上。
- 下一次请求时，客户端带着Cookie来请求服务器，服务端从Cookie中取出SessionId，从而实现用户会话状态的保持。
- 第一次登陆后，服务端生成Token给客户端，客户端之后带着Token请求数据即可。减轻服务器的压力，减少频繁查询数据库。
25.2 不同会话状态的区别
- Cookie：在客户端保存用户信息，安全性较差，并且浏览器会限制cookie数量。例如： 保存登录用户信息，下次自动填写登录信息；登录网 站后访问其他页面就不用登录。
- Session：在服务端记录用户状态，安全性较高，但占用服务器性能。例如：购物车添加物品，根据Session知道用户的购物车。
- Token：在客户端保存认证授权状态，适合前后端分离的项目(处于不同服务器)。
26. IP 地址有哪些分类？
一般可以这么认为，IP 地址 = 网络号 + 主机号。
- 网络号：它标志主机所连接的网络地址表示属于互联网的哪一个网络。
- 主机号：它标志主机地址表示其属于该网络中的哪一台主机。
IP 地址分为 A，B，C，D，E 五大类：
- A 类地址 (1~126)：以 0 开头，网络号占前 8 位，主机号占后面 24 位。
- B 类地址 (128~191)：以 10 开头，网络号占前 16 位，主机号占后面 16 位。
- C 类地址 (192~223)：以 110 开头，网络号占前 24 位，主机号占后面 8 位。
- D 类地址 (224~239)：以 1110 开头，保留位多播地址。
- E 类地址 (240~255)：以 11110 开头，保留位为将来使用
IP 地址分类
27. 说下 ARP 协议的工作过程？
ARP 协议协议，Address Resolution Protocol，地址解析协议，它是用于实现 IP 地址到 MAC 地址的映射。
- 首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。
- 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己的 ARP 列表，是否存在该 IP 地址对应的 MAC 地址；如果有﹐就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。此 ARP 请求的数据包里，包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。
- 网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同，就会忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址。
- 源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。
28. 有了 IP 地址，为什么还要用 MAC 地址？
- 简而言之，标识网络中的一台计算机，比较常用的就是IP 地址和 MAC 地址，但计算机的 IP 地址可由用户自行更改，管理起来就相对困难，而 MAC 地址不可更改，所以一般会把 IP 地址和 MAC 地址组合起来使用。
- 那只使用 MAC 地址不用 IP 地址行不行呢？不行的！因为最早就是 MAC 地址先出现的，并且当时并不用 IP 地址，只用 MAC 地址，后来随着网络中的设备越来越多，整个路由过程越来越复杂，便出现了子网的概念。对于目的地址在其他子网的数据包，路由只需要将数据包送到那个子网即可。
- 那为什么要用 IP 地址呢？是因为 IP 地址是和地域相关的，对于同一个子网上的设备，IP 地址的前缀都是一样的，这样路由器通过 IP 地址的前缀就知道设备在在哪个子网上了，而只用 MAC 地址的话，路由器则需要记住每个 MAC 地址在哪个子网，这需要路由器有极大的存储空间，是无法实现的。
- IP 地址可以比作为地址，MAC 地址为收件人，在一次通信过程中，两者是缺一不可的。
29. TCP 和 UDP 分别对应的常见应用层协议有哪些？
基于 TCP 的应用层协议有：HTTP、FTP、SMTP、TELNET、SSH
- HTTP：HyperText Transfer Protocol（超文本传输协议），默认端口 80
- FTP: File Transfer Protocol (文件传输协议), 默认端口 (20 用于传输数据，21 用于传输控制信息)
- SMTP: Simple Mail Transfer Protocol (简单邮件传输协议) , 默认端口 25
- TELNET: Teletype over the Network (网络电传), 默认端口 23
- SSH：Secure Shell（安全外壳协议），默认端口 22
基于 UDP 的应用层协议：DNS、TFTP、SNMP
- DNS : Domain Name Service (域名服务), 默认端口 53
- TFTP: Trivial File Transfer Protocol (简单文件传输协议)，默认端口 69
- SNMP：Simple Network Management Protocol（简单网络管理协议），通过 UDP 端口 161 接收，只有 Trap 信息采用 UDP 端口 162。
30. 聊聊保活计时器的作用（客户端连接成功之后发生故障怎么处理）
除时间等待计时器外，TCP 还一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10 个探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。
31. 如果服务器出现了大量 CLOSE_WAIT 状态如何解决。
我们先来复习下 TCP 的四次挥手
- 服务器端收到客户端发送的
FIN后，TCP 协议栈就会自动发送 ACK，接着进入CLOSE_WAIT状态。 - 但是如果服务器端不执行 socket 的 close() 操作，那么就没法进入 LAST_ACK, 导致大量连接处于 CLOSE_WAIT 状态
- 所以，如果服务器出现了大量CLOSE_WAIT状态，一般是程序 Bug，或者关闭 socket 不及时。
32. URI 和 URL 的区别
- URI，全称是 Uniform Resource Identifier)，中文翻译是统一资源标志符，主要作用是唯一标识一个资源。
- URL，全称是 Uniform Resource Location)，中文翻译是统一资源定位符，主要作用是提供资源的路径。打个经典比喻吧，URI 像是身份证，可以唯一标识一个人，而 URL 更像一个住址，可以通过 URL 找到这个人。
33. ICMP 协议的功能
ICMP,Internet Control Message Protocol ,Internet 控制消息协议。
- ICMP 协议是一种面向无连接的协议，用于传输出错报告控制信息。
- 它是一个非常重要的协议，它对于网络安全具有极其重要的意义。它属于网络层协议，主要用于在主机与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。
- 当遇到 IP 数据无法访问目标、IP 路由器无法按当前的传输速率转发数据包等情况时，会自动发送 ICMP 消息。
比如我们日常使用得比较多的ping，就是基于 ICMP 的。
35. 说下 ping 的原理
ping，Packet Internet Groper，是一种因特网包探索器，用于测试网络连接量的程序。Ping 是工作在 TCP/IP 网络体系结构中应用层的一个服务命令， 主要是向特定的目的主机发送 ICMP（Internet Control Message Protocol 因特网报文控制协议） 请求报文，测试目的站是否可达及了解其有关状态
一般来说，ping 可以用来检测网络通不通。它是基于ICMP协议工作的。假设机器 A ping机器 B，工作过程如下：
- ping 通知系统，新建一个固定格式的 ICMP 请求数据包
- ICMP 协议，将该数据包和目标机器 B 的 IP 地址打包，一起转交给 IP 协议层
- IP 层协议将本机 IP 地址为源地址，机器 B 的 IP 地址为目标地址，加上一些其他的控制信息，构建一个 IP 数据包
- 先获取目标机器 B 的 MAC 地址。
- 数据链路层构建一个数据帧，目的地址是 IP 层传过来的MAC 地址，源地址是本机的MAC 地址
- 机器 B 收到后，对比目标地址，和自己本机的 MAC 地址是否一致，符合就处理返回，不符合就丢弃。
- 根据目的主机返回的 ICMP 回送回答报文中的时间戳，从而计算出往返时间
- 最终显示结果有这几项：发送到目的主机的 IP 地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大 & 平均值
总结：ping的工作过程
- 向目的主机发送多个ICMP回送请求报文
- 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。
36. 请详细介绍一下 TCP 的三次握手机制
思路: TCP 连接的三次握手机制，最重要的知识点，必须得会，通讯过程以及客户端、服务器的对应的状态都需要记住哈。
TCp 提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的就是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。我们一起来看下流程图哈：
流程：
- 第一次握手 (发送连接请求报文SYN=1, 初始序号随机seq=x，ACK=0)，发送完毕后，客户端就进入 SYN_SENT 状态
- 第二次握手 (发送连接确认报文SYN=1, ACK=1, seq=y, ACKnum=x+1)， 发送完毕后，服务器端就进入 SYN_RCV 状态。
- 第三次握手 (发出连接确认报文ACK=1，ACKnum=y+1，序号seq=x+1)，发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态。
ACK也好，ack也好，只不过是个代号而已
ACK是确认值(Acknowledgement)，为1便是确认连接。
ack是确认编号(Acknowledgement Number)，即接收到的上一次远端主机传来的seq然后+1，再发送给远端主机。提示远端主机已经成功接收上一次所有数据。
37. TCP 握手为什么是三次，为什么不能是两次？不能是四次？
思路: TCP 握手为什么不能是两次，为什么不能是四次呢？为了方便理解，我们以男孩子和女孩子谈恋爱为例子：两个人能走到一起，最重要的事情就是相爱，就是我爱你，并且我知道，你也爱我，接下来我们以此来模拟三次握手的过程：
为什么握手不能是两次呢？
如果只有两次握手，女孩子可能就不知道，她的那句我也爱你，男孩子是否收到，恋爱关系就不能愉快展开。
为什么握手不能是四次呢？
因为握手不能是四次呢？因为三次已经够了，三次已经能让双方都知道：你爱我，我也爱你。而四次就多余了。
总结：
确保可靠的通信通道，让双方都确认对方和自己的接收和发送功能是正常的。
将三次握手通俗的说。
- 第一次握手，Server知道Client的发送能力和自己的接收能力是正常的。
- 第二次握手，Client知道Server的发送和接收能力和自己的发送和接收能力是正常的，但是Server还不知道我的接收和他的发送能力正常与否。
- 第三次握手，Client回馈，让Server知道自己的发送能力和Client的接收能力正常。
38. 说说 TCP 四次挥手过程
思路: TCP 的四次挥手，也是最重要的知识点，一般跟三次握手会一起考的，必须得记住。
TCP 四次挥手过程
- Client状态变化：Fin-Wait-1 -> Fin-Wait-2 -> Time-Wait -> Closed
- Server状态变化：Close-Wait -> Last-Ack -> Closed
具体流程：
- 第一次挥手：客户端发送连接释放报文FIN=1，序号(握手时初始序号 + 发送的字节数据数量 + 1)seq=u，发送完毕后，客户端进入FIN_WAIT_1状态。
- 第二次挥手：服务器发出确认收到报文ACK=1，确认号ack=u+1，序列号(握手时初始序号 + 回复的字节数据)seq=v，发送完毕后，服务器端进入CLOSE_WAIT状态，客户端接收到这个确认包之后，进入FIN_WAIT_2状态。
- 第三次挥手：关闭连接，发送连接释放报文FIN=1，确认号ack=u+1，初始序号seq=w，发送完毕后，服务器端进入LAST_ACK状态，等待来自客户端的最后一个 ACK。
- 第四次挥手： 客户端接收到来自服务器端的关闭请求，发回确认收到报文ACK=1，确认序号seq=w+1，初始序号ack=u+1，客户端进入 TIME_WAIT 状态，等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
39. TCP 挥手为什么需要四次呢？
思路： TCP 挥手为什么需要四次呢？为了方便大家理解，再举个生活的例子吧。
★ 小明和小红打电话聊天，通话差不多要结束时，小红说，“我没啥要说的了”。小明回答，“我知道了”。但是小明可能还有要说的话，小红不能要求小明跟着她自己的节奏结束通话，于是小明可能又叽叽歪歪说了一通，最后小明说，“我说完了”，小红回答，“我知道了”，这样通话才算结束。
总结：
Server端可能还有数据没有发送完毕。Client发出连接释放通知，Server确认收到后，Client就进入半关闭状态（只收消息不发消息），Server把未发完的数据发送完毕后，发送连接释放通知，Client确认后就关闭连接。
40. TCP 四次挥手过程中，为什么需要等待 2MSL, 才进入 CLOSED 关闭状态
思路： 这个问得频率特别高。去面试前，一定要把这道题拿下哈。
2MSL，two Maximum Segment Lifetime，即两个最大段生命周期。假设主动发起挥手的是客户端，那么需要 2MSL 的原因是：
- 1. 为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报文段有可能丢失，因而使处在LAST-ACK状态的服务端就收不到对已发送的FIN + ACK报文段的确认。服务端会超时重传这个 FIN+ACK 报文段，而客户端就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着客户端重传一次确认，重新启动 2MSL 计时器。最后，客户端和服务器都正常进入到CLOSED状态。（简述：防止ack报文丢失，Server再次发送Fin报文，一来一回最长时间就是2MSL）
- 2. 防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。
41. TCP 的粘包和拆包
TCP 是面向流，没有界限的一串数据。TCP 底层并不了解上层业务数据的具体含义，它会根据 TCP 缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被 TCP 拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的 TCP 粘包和拆包问题。
TCP 的粘包和拆包
为什么会产生粘包和拆包呢?
- 要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包；
- 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；
- 要发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包；
- 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包。即 TCP 报文长度 - TCP 头部长度 > MSS。
解决方案：
- 发送端将每个数据包封装为固定长度
- 在数据尾部增加特殊字符进行分割
- 将数据分为两部分，一部分是头部，一部分是内容体；其中头部结构大小固定，且有一个字段声明内容体的大小。
42. 聊聊 TCP 的流量控制
TCP 三次握手，发送端和接收端进入到 ESTABLISHED 状态，它们即可以愉快地传输数据啦。
但是发送端不能疯狂地向接收端发送数据，因为接收端接收不过来的话，接收方只能把处理不过来的数据存在缓存区里。如果缓存区都满了，发送方还在疯狂发送数据的话，接收方只能把收到的数据包丢掉，这就浪费了网络资源啦。
★ TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量，这就是流量控制。
TCP 通过滑动窗口来控制流量，我们看下流量控制的简要流程吧：
首先双方三次握手，初始化各自的窗口大小，均为 400 个字节。
TCP 的流量控制
- 假如当前发送方给接收方发送了 200 个字节，那么，发送方的
SND.NXT会右移 200 个字节，也就是说当前的可用窗口减少了 200 个字节。 - 接受方收到后，放到缓冲队列里面，REV.WND =400-200=200 字节，所以 win=200 字节返回给发送方。接收方会在 ACK 的报文首部带上缩小后的滑动窗口 200 字节
- 发送方又发送 200 字节过来，200 字节到达，继续放到缓冲队列。不过这时候，由于大量负载的原因，接受方处理不了这么多字节，只能处理 100 字节，剩余的 100 字节继续放到缓冲队列。这时候，REV.WND = 400-200-100=100 字节，即 win=100 返回发送方。
- 发送方继续干活，发送 100 字节过来，这时候，接受窗口 win 变为 0。
- 发送方停止发送，开启一个定时任务，每隔一段时间，就去询问接受方，直到 win 大于 0，才继续开始发送。
43. 说说半连接队列和 SYN Flood 攻击的关系
思路讲解： 我以前面试的时候，面试官就问我什么是半连接队列、什么是全连接队列，哈哈。我们需要掌握半连接队列、全连接对列是啥，还需要清楚半连接队列和 SYN Flood 攻击有什么关系。
我的答案如下：
TCP 进入三次握手前，服务端会从CLOSED状态变为LISTEN状态, 同时在内部创建了两个队列：半连接队列（SYN 队列）和全连接队列（ACCEPT 队列）。
什么是半连接队列（SYN 队列） 呢? 什么是全连接队列（ACCEPT 队列） 呢？回忆下 TCP 三次握手的图：
三次握手
- TCP 三次握手时，客户端发送 SYN 到服务端，服务端收到之后，便回复ACK 和 SYN，状态由LISTEN 变为 SYN_RCVD，此时这个连接就被推入了SYN 队列，即半连接队列。
- 当客户端回复 ACK, 服务端接收后，三次握手就完成了。这时连接会等待被具体的应用取走，在被取走之前，它被推入 ACCEPT 队列，即全连接队列。
SYN Flood 是一种典型的 DDos 攻击，它在短时间内，伪造不存在的 IP 地址, 向服务器大量发起 SYN 报文。当服务器回复 SYN+ACK 报文后，不会收到 ACK 回应报文，导致服务器上建立大量的半连接半连接队列满了，这就无法处理正常的 TCP 请求啦。
那么有哪些方案应对呢？主要有 syn cookie和SYN Proxy 防火墙等。
★
- syn cookie：在收到 SYN 包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个 cookie 值作为自己的 SYNACK 包的序列号，回复 SYN+ACK 后，服务器并不立即分配资源进行处理，等收到发送方的 ACK 包后，重新根据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建立连接，否则丢弃该包。
- SYN Proxy 防火墙：服务器防火墙会对收到的每一个 SYN 报文进行代理和回应，并保持半连接。等发送方将 ACK 包返回后，再重新构造 SYN 包发到服务器，建立真正的 TCP 连接。
44. 聊聊 TCP 的滑动窗口
思路讲解： TCP 滑动窗口是个高频考点，我们需要知道 TCP 报文首部有个字段win控制窗口大小的，同时也需要掌握，滑动窗口是怎么滑的。
TCP 发送一个数据，如果需要收到确认应答，才会发送下一个数据。这样的话就会有个缺点：效率会比较低。
★ 这就好像我们面对面在聊天，你说完一句，我应答之后，你才能说下一句。那么，如果我在忙其他事情，没有能够及时回复你呢？你说完一句后，要等到我忙完回复你，你才说下句，这显然不现实，效率太低。
为了解决这个问题，TCP 引入了窗口，它是操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答，而可以继续发送数据的最大值。
TCP 头部有个字段叫 win，也即那个16 位的窗口大小，它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度，从而达到流量控制的目的。
★ 通俗点讲，就是接受方每次收到数据包，在发送确认报文的时候，同时告诉发送方，自己的缓存区还有多少空余空间，缓冲区的空余空间，我们就称之为接受窗口大小。这就是 win。
TCP 滑动窗口分为两种: 发送窗口和接收窗口。发送端的滑动窗口包含四大部分，如下：
- 已发送且已收到 ACK 确认
- 已发送但未收到 ACK 确认
- 未发送但可以发送
- 未发送也不可以发送
- 虚线矩形框，就是发送窗口。
- SND.WND: 表示发送窗口的大小, 上图虚线框的格子数是 14 个，即发送窗口大小是 14。
- SND.NXT：下一个发送的位置，它指向未发送但可以发送的第一个字节的序列号。
- SND.UNA: 一个绝对指针，它指向的是已发送但未确认的第一个字节的序列号。
接收方的滑动窗口包含三大部分，如下：
- 已成功接收并确认
- 未收到数据但可以接收
- 未收到数据并不可以接收的数据
- 虚线矩形框，就是接收窗口。
- REV.WND: 表示接收窗口的大小, 上图虚线框的格子就是 9 个。
- REV.NXT: 下一个接收的位置，它指向未收到但可以接收的第一个字节的序列号。
45. TCP 的拥塞控制
思路讲解： TCP 拥塞机制也是个高频考点，需要掌握它跟流量控制的区别，也需要掌握拥塞控制的这几种算法：慢启动算法、拥塞避免、快速重传、快速恢复算法。
拥塞控制是作用于网络的，防止过多的数据包注入到网络中，避免出现网络负载过大的情况。它的目标主要是最大化利用网络上瓶颈链路的带宽。它跟流量控制又有什么区别呢？流量控制是作用于接收者的，根据接收端的实际接收能力控制发送速度，防止分组丢失的。
我们可以把网络链路比喻成一根水管，如果我们想最大化利用网络来传输数据，那就是尽快让水管达到最佳充满状态。
发送方维护一个拥塞窗口 cwnd（congestion window） 的变量，用来估算在一段时间内这条链路（水管）可以承载和运输的数据（水）的数量。它大小代表着网络的拥塞程度，并且是动态变化的，但是为了达到最大的传输效率，我们该如何知道这条水管的运送效率是多少呢？
一个比较简单的方法就是不断增加传输的水量，直到水管快要爆裂为止（对应到网络上就是发生丢包），用 TCP 的描述就是：
★ 只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。
实际上，拥塞控制主要有这几种常用算法
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
45.1 慢启动算法（慢开始）
cwnd初始值为1，每个轮次cwnd加倍
慢启动算法，表面意思就是，别急慢慢来。它表示 TCP 建立连接完成后，一开始不要发送大量的数据，而是先探测一下网络的拥塞程度。由小到大逐渐增加拥塞窗口的大小，如果没有出现丢包，每收到一个 ACK，就将拥塞窗口 cwnd 大小就加 1（单位是 MSS）。每轮次发送窗口增加一倍，呈指数增长，如果出现丢包，拥塞窗口就减半，进入拥塞避免阶段。
- TCP 连接完成，初始化 cwnd = 1，表明可以传一个 MSS 单位大小的数据。
- 每当收到一个 ACK，cwnd 就加一;
- 每当过了一个 RTT，cwnd 就增加一倍; 呈指数让升
为了防止 cwnd 增长过大引起网络拥塞，还需设置一个慢启动阀值 ssthresh（slow start threshold）状态变量。当cwnd到达该阀值后，就好像水管被关小了水龙头一样，减少拥塞状态。即当cwnd >ssthresh时，进入了拥塞避免算法。
45.2 拥塞避免算法
慢开始门限ssthresh，当cwnd>ssthresh时，进入拥塞避免，让cwnd每个轮次+1。出现超时，就令ssthresh = cwnd/2，重新进行慢开始。
一般来说，慢启动阀值 ssthresh 是 65535 字节，cwnd到达慢启动阀值后
- 每收到一个 ACK 时，cwnd = cwnd + 1/cwnd
- 当每过一个 RTT 时，cwnd = cwnd + 1
显然这是一个线性上升的算法，避免过快导致网络拥塞问题。
45.3 拥塞发生(快速重传）
接收方只对最后一个收到的有序报文段进行确认，若发送方介绍重复确认，就判断下一个报文段丢失，执行快重传，即立即重传下一报文段。
当网络拥塞发生丢包时，会有两种情况：
- RTO 超时重传
- 快速重传
如果是发生了RTO 超时重传，就会使用拥塞发生算法
- 慢启动阀值 sshthresh = cwnd /2
- cwnd 重置为 1
- 进入新的慢启动过程
这真的是辛辛苦苦几十年，一朝回到解放前。其实还有更好的处理方式，就是快速重传。发送方收到 3 个连续重复的 ACK 时，就会快速地重传，不必等待RTO 超时再重传。
慢启动阀值 ssthresh 和 cwnd 变化如下：
- 拥塞窗口大小 cwnd = cwnd/2
- 慢启动阀值 ssthresh = cwnd
- 进入快速恢复算法
45.4 快速恢复
若丢失个别报文段，执行快恢复，令ssthresh = cwnd/2, cwnd = ssthresh，直接进入拥塞避免。
快速重传和快速恢复算法一般同时使用。快速恢复算法认为，还有 3 个重复 ACK 收到，说明网络也没那么糟糕，所以没有必要像 RTO 超时那么强烈。
正如前面所说，进入快速恢复之前，cwnd 和 sshthresh 已被更新：
- cwnd = cwnd /2 - sshthresh = cwnd
然后，真正的快速算法如下：
- cwnd = sshthresh + 3
- 重传重复的那几个 ACK（即丢失的那几个数据包）
- 如果再收到重复的 ACK，那么 cwnd = cwnd +1
- 如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK，表明恢复过程已经结束，可以再次进入了拥塞避免的算法了。
总结：
拥塞控制是为了防止过多数据注入网络，导致网络过载。TCP的拥塞控制采用四个算法实现：慢开始、拥塞避免、快重传、快恢复。 发送方维护一个拥塞窗口(cwnd)的状态变量。
- 慢开始：cwnd初始值为1，每个轮次cwnd加倍
- 拥塞避免：慢开始门限ssthresh，当cwnd>ssthresh时，进入拥塞避免，让cwnd每个轮次+1。出现超时，就令ssthresh = cwnd/2，重新进行慢开始。
- 快重传：接收方只对最后一个收到的有序报文段进行确认，若发送方介绍重复确认，就判断下一个报文段丢失，执行快重传，即立即重传下一报文段。
- 快恢复：若丢失个别报文段，执行快恢复，令ssthresh = cwnd/2, cwnd = ssthresh，直接进入拥塞避免。
46. 请简述 TCP 和 UDP 的区别
思路： 这道题，校招的时候，问的概率高点，概念性的东西，TCP 是面向连接，而 UDP 是无连接。
| 类型 | 特点 | 性能 | 应用场景 | 首部字节 | |||
|---|---|---|---|---|---|---|---|
| 是否面向链接 | 传输可靠性 | 传输形式 | 传输效率 | 消耗资源 | |||
| TCP | 面向连接 | 可靠 | 字节流 | 慢 | 多 | 要求通信数据可靠 （文件/邮件传输） | 20~60 |
| UDP | 无连接 | 不可靠 | 数据报文段 | 快 | 少 | 要求通信速度高 （视频/语音传输） | 8 （由4个字段组成） |
总结：
- TCP：面向连接的可靠交付，以字节流传输，效率低，耗费资源少，适用于对通信数据严格的场景，如文件传输。首部20-60字节。
- UDP：无连接的尽最大努力交付，以数据报文段传输，速度快，耗费资源少，适用于对通信速度要求高的场景，如在线视频。首部8个字节。
46.1 为什么视频用UDP
- TCP需要三次握手，建立会话需要时间；
- TCP在网络拥塞时，会调整滑动窗口大小，影响传输速度；
- UDP无连接，没有拥塞控制，会以恒定速度发送数据，缺点是造成丢包，优点是实时性好。
46.2 UDP处理丢包
- 发生丢包，就立即发送冗余包，尽快恢复数据；
- 建立长期参考帧，解决连贯性问题；
- 发生网络抖动，降低码率，保证传输数据小于网络带宽。
47. 说说 TCP 是如何确保可靠性的呢？
思路： TCP 是可靠的连接，为什么具有可靠性呢？记住这些点：连接和断开的可靠性（三次握手，四次挥手）、有状态（哪些数据发送了，哪些没发）、可控制（超时重传、流量控制、拥塞控制等）。
- 首先，TCP 的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的可靠性。
- 其次，TCP 的可靠性，还体现在有状态;TCP 会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
- 再次，TCP 的可靠性，还体现在可控制。它有数据包校验、ACK 应答、超时重传 (发送方)、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。
48. 说说 TCP 报文首部有哪些字段，其作用又分别是什么？
思路： 小伙伴们，可以记下这个图。
- 16 位端口号：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序
- 32 位序号：一次 TCP 通信（从 TCP 连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。
- 32 位确认号：用作对另一方发送的 tcp 报文段的响应。其值是收到的 TCP 报文段的序号值加 1。
- 4 位头部长度：表示 tcp 头部有多少个 32bit 字（4 字节）。因为 4 位最大能标识 15，所以 TCP 头部最长是 60 字节。
- 6 位标志位：URG(紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了）
- 16 位窗口大小：是 TCP 流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。
- 16 位校验和：由发送端填充，接收端对 TCP 报文段执行 CRC 算法以检验 TCP 报文段在传输过程中是否损坏。注意，这个校验不仅包括 TCP 头部，也包括数据部分。这也是 TCP 可靠传输的一个重要保障。
- 16 位紧急指针：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP 的紧急指针是发送端向接收端发送紧急数据的方法。
49. Nagle 算法与延迟确认
49.1 Nagle 算法
如果发送方疯狂地向接收方发送很小的数据包，比如一次就发送 1 个字节，那么显然会有问题。
TCP/IP 协议中，无论发送多少数据，总是需要在数据前面加上协议头，同时，对方接收到数据，也需要发送 ACK 表示确认。为了尽可能的利用网络带宽，TCP 总是希望尽可能的发送足够大的数据。Nagle 算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。
Nagle 算法：任意时刻，最多只能有一个未被确认的小段。所谓 “小段”，指的是小于 MSS 尺寸的数据块，所谓 “未被确认”，是指一个数据块发送出去后，没有收到对方发送的 ACK 确认该数据已收到。
Nagle 算法的实现规则：
- 如果包长度达到 MSS，则允许发送；
- 如果该包含有 FIN，则允许发送；
- 设置了 TCP_NODELAY 选项，则允许发送；
- 未设置 TCP_CORK 选项时，若所有发出去的小数据包（包长度小于 MSS）均被确认，则允许发送；
- 上述条件都未满足，但发生了超时（一般为 200ms），则立即发送。
49.2 延迟确认
如果接受方刚接收到发送方的数据包，在很短很短的时间内，又接收到第二个包。那么请问接收方是一个一个地回复好点，还是合在一起回复好呢？
接收方收到数据包后，如果暂时没有数据要发给对端，它可以等一小段时间，再确认（Linux 上默认是 40ms）。如果这段时间刚好有数据要传给对端，ACK 就随着数据传输，而不需要单独发送一次 ACK。如果超过时间还没有数据要发送，也发送 ACK，避免对端以为丢包。
但是有些场景不能用延迟确认，比如发现了乱序包、接收到了大于一个 frame 的报文，且需要调整窗口大小等。
一般情况下，Nagle 算法和延迟确认不能一起使用，Nagle 算法意味着延迟发，延迟确认意味着延迟接收，酱紫就会造成更大的延迟，会产生性能问题。
50. 说说 TCP 的重传机制
思路讲解： TCP 的重传机制，也是道非常高频的面试题。重传包括超时重传、快速重传、带选择确认的重传（SACK）、重复 SACK 四种。
50.1 超时重传
超时重传，是 TCP 协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的 ACK 报文，那么就重新发送数据，直到发送成功为止。
这个一定时间内，一般是多少比较合理呢？来看下什么叫RTT（Round-Trip Time，往返时间）。
RTT 就是数据完全发送完，到收到确认信号的时间，即数据包的一次往返时间。超时重传时间，就是 RTO（Retransmission Timeout)。
那么，RTO 到底设置多大呢？
- 如果 RTO 设置很大，等了很久都没重发，这样肯定就不行。
- 如果 RTO 设置很小，那很可能数据都没有丢失，就开始重发了，这会导致网络阻塞，从而恶性循环，导致更多的超时出现。
一般来说，RTO 略微大于 RTT，效果是最佳的。其实，RTO 有个标准方法的计算公式，也叫Jacobson / Karels 算法。一起来看下吧：
1. 首先计算 SRTT（即计算平滑的 RTT）
SRTT = (1 - α) * SRTT + α * RTT // 求 SRTT 的加权平均
2. 其次，计算 RTTVAR (round-trip time variation)
RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) // 计算 SRTT 与真实值的差距
3. 最后，得出最终的 RTO
RTO = µ * SRTT + ∂ * RTTVAR = SRTT + 4·RTTVAR
一般情况，α、β等的参数取值如下：
α = 0.125，β = 0.25， μ = 1，∂ = 4
别问这些参数是怎么来的，它们是大量实践，调出的最优参数。
超时重传不是十分完美的重传方案，它有这些缺点：
- 当一个报文丢失时，会等待一定的超时周期，才重传分组，增加了端到端的时延。
- 当一个报文丢失时，在其等待超时的过程中，可能会出现这种情况：其后的报文段已经被接收端接收但却迟迟得不到确认，发送端会认为也丢失了，从而引起不必要的重传，既浪费资源也浪费时间。
并且，对于 TCP，如果发生一次超时重传，时间间隔下次就会加倍。
总结：
超时重传：若一个已经发送的报文段在超时时间内没有收到确认，就重传这个报文段。超时时间RTO略大于加权往返时间RTTs。往返时间RTT指一个报文段从发送再到接收到确认所经过的时间。
50.2 快速重传
其实可以使用快速重传，来解决超时重发的时间等待问题。它不以时间驱动，而是以数据驱动。它是基于接收端的反馈信息来引发重传的。快速重传流程如下：
快速重传流程
发送方发送了 1，2，3，4，5,6 份数据:
- 第一份 Seq=1 先送到了，于是就 Ack 回 2；
- 第二份 Seq=2 也送到了，于是 ACK 回 3；
- 第三份 Seq=3 由于网络等某些原因，没送到；
- 第四份 Seq=4 送到了，但是由于 Seq=3 没收到。因此 ACK 还是回 3；
- 后面的 Seq=5,6 的也送到了，ACK 还是回复 3，因为 Seq=3 没有收到。
- 发送方连着收到三个重复冗余 ACK=3 的确认（其实是 4 个哈，但是因为前面的一个是正常的 ACK，后面三个才是重复冗余的），于是知道哪个报文段在传输过程中丢失了；发送方在定时器过期之前，重传该报文段。
- 最后，接收方收到了 Seq=3，此时因为 Seq=4，5，6 都收到了，于是它回 ACK=7。
但是呢，快速重传也可能有问题：ACK 只向告知发送方，最大的有序报文段。到底是哪个报文丢失了呢？并不确定！那到底该重传多少个包呢？
★ 是重传 Seq=3 ？还是重传 Seq=3、Seq=4、Seq=5、Seq=6 呢？因为发送端并不清楚这三个连续的 ACK=3 是谁传回来的。
50.3 带选择确认的重传（SACK）
为了解决：应该重传多少个包的问题? TCP 提供了带选择确认的重传（即 SACK，Selective Acknowledgment）。
★ SACK 机制就是，在快速重传的基础上，接收方返回最近收到报文段的序列号范围，这样发送方就知道接收方哪些数据包是没收到的。这样就很清楚应该重传哪些数据包啦。
SACK 机制
如上图中，发送方收到了三次同样的 ACK=30 的确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有30~39这段数据丢失，于是重发时，就只选择了这个30~39的 TCP 报文段进行重发。
50.4 重复 SACK（D-SACK）
★ D-SACK，英文是 Duplicate SACK，是在 SACK 的基础上做了一些扩展，主要用来告诉发送方，有哪些数据包，自己重复接受了。DSACK 的目的是帮助发送方判断，是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。来看个图吧：
D-SACK 简要流程
51. UDP首部
UDP的首部只有8个字节，源端口号、目的端口号、长度和校验和各两个字节
参考资料
[1] http 的长连接和短连接（史上最通俗！）: https://www.jianshu.com/p/3fc3646fad80
[2] Cookie 和 Session 的区别: https://zhuanlan.zhihu.com/p/66754258
[3] ARP 协议的工作机制详解: http://c.biancheng.net/view/6388.html
[4] ARP 协议工作流程: https://blog.csdn.net/qq_44041062/article/details/109844155
[5]一文搞定所有计算机网络面试题: https://segmentfault.com/a/1190000038526729
[
](https://www.eet-china.com/mp/a68780.html)
交流答疑qq群：1007576722