HTTP

1. http报文格式？

• HTTP 请求报文
• HTTP 请求报文由请求行、请求头、空行 和 请求体组成
• 请求行：包括请求方法，URL，HTTP版本。请求头：客户端的属性信息。主要有cookie、host、connection、Accept；请求体：用户请求数据。
• HTTP响应报文
• HTTP响应报文由状态线、响应头、空行和响应体组成
• 状态行：HTTP版本、状态码和状态描述。 响应头：服务器属性信息，Set-Cookie、connection、Content-Length； 响应体：服务器返回到客户端。

1. IP 、TCP/UDP、 HTTP、SMTP、DNS、FTP分别在哪层？
2. IP --- 网络层TCP/UDP --- 传输层HTTP、DNS、SMTP、FTP -- 应用层协议
3. http常用字段

• 请求头：
• Accept: 告诉服务器可接受的文件类型
• Host：服务器想要访问的服务器域名或IP
• Connection: 管理连接的耐久性，Keep-Alive：长连接，close：短连接
• Accept-Encoding ：告诉服务器浏览器支持什么编码
• Accept-Language ：支持的语言 ；
• User-Agent：浏览器的类型
• 响应头：
• Content-Length:响应体的长度
• Server：服务器信息
• Content-Type：内容类型，text／html，xml等

1. 为什么说http是无状态的吗？
2. http对发送的请求或响应不持久，多个请求是独立的。
3. HTTP请求方式？

• GET
• 在不修改数据的情况下，向服务器获取指定资源
• POST
• 向服务器提交数据
• PUT
• 与POST类似地，将数据发送到服务器，但具有功率等特性，通常用于更新
• 补充：HTTP方法的幂等性同一请求被执行一次，连续执行多次效果是一样的；
• DELETE
• 用于删除服务器指定的资源

1. GET和POST区别？
2. ① GET而且post提交数据
3. ② GET请求参数通过URL传递，POST请求体中的参数。③ GET请求会把 header 和 data 一起发送；和 post 会先发 header 收到 100 响应状态码后再发送 data④ GET浏览器将提出请求主动缓存，而POST不，除非手动设置。(订单的例子)
4. ⑤ GET 是幂等的，post 不是幂等的。
5. ⑥ GET发送的报纸长度有限，最大约2k，POST报文无此限制；
7. HTTP长连接和短连接？
8. HTTP1.0默认使用短连接。浏览器和服务器每次进行一次HTTP操作时，建立连接，任务结束时中断连接。
9. HTTP1.1起，默认使用长连接。使用长连接、客户端和服务器HTTP首部的Connection字段都要设置为keep-alive，支持长连接。
10. HTTP长连接，指的是复用TCP连接。多个HTTP同一个请求可以重用TCP连接，可以节省TCP建立和断开连接的消耗。
11. HTTP1.0和 HTTP1.1的区别？
12. HTTP1.1的新特性：
13. ① 支持长连接：避免每次客户端和服务器都要求建立和释放TCP连接；
14. ② 引入了更多的缓存控制策略
15. ③ 增加Host字段
16. ④ 支持断点传输等
17. HTTP1.1和 HTTP2.0的区别？
18. HTTP2.0的新特性：
19. ①采用二进制格式传输数据，分析效率更高HTTP1.1 传输基于文本格式的数据。
20. ② 多路复用：在一个TCP在连接中，多个请求或响应可以平行传输而不被阻塞；
21. ③ 头部压缩： 使用特定算法压缩头帧，有效减少头部信息的大小，双方各自通信header fields表，避免重复header的传输。
22. ④ 服务推送：HTTP2.0允许服务器将资源推送到客户端。
23. HTTP 3.0新特性
24. 放弃了tcp协议改用了 QUIC协议，本协议以传输层为基础UDP协议。
25. QUIC基本特点：
26. 连接建立时间短；
27. 改善拥塞控制；
28. 一条 QUIC 连接上的多个请求之间没有依赖性；
29. 采用向前纠错方案，减少包的重传；
31. HTTPS与HTTP的区别？
32. ① HTTP信息传输简单但不安全；HTTPS它是安全的ssl加密传输协议，但复杂。
33. ② HTTP和HTTPS使用的端口不同，HTTP端口是80，HTTPS是443。
34. ③https需要认证证书 ，而http不需要
35. HTTP安全问题：
36. 窃听：可能被第三方窃听 伪装：无法确认通信双方的身份信息 篡改：报纸也可能被篡改：
37. HTTPS解决方案：
38. 加密：对称密钥和非对称密钥
39. 认证：引进CA
40. 防篡改:传输时计算报文 md5 摘要一起传过去
41. https建立过程（SSL建立过程)
42. ① 客户端向服务端发送支持的加密算法和随机数1；
43. ② 将选定的加密算法返回客户端，包括服务器公钥证书和随机数2；
44. ③ 客户端验证服务器证书，提取服务器公钥，生成发送给服务器的前主密钥；
45. ④ 客户端和服务器根据前主密钥和两个随机数计算当前会话的主密钥；
46. ⑤ 开始传输数据，使用相同的对称密钥加解密。
47. 常见响应码？301和302的区别？502和504的区别？
48. 100 Continue 到目前为止，所有内容都是可行的，客户应该继续要求。
49. 200 OK 请求成功。
50. 301 Moved Permanently 资源已被要求永久浏览器将自动定位到新位置URI。未来任何新的请求都将使用新的请求URI代替。
51. 302 Found 临时重定向。资源只是。临时被移动，原始请求应在未来继续使用URI。
52. 404 Not Found 请求失败，请求资源未在服务器上找到。
53. 500 Internal Server Error 服务器遇到了不知处理。
54. 502 Bad Gateway 服务器充当网关，从远端服务器接收一个无效(错误)的请求。 504 Gateway TimeOut充当网关服务器，未及时从远端服务器获取请求。
56. http长连接有什么用？例如，长连接的连接数有限吗？
57. 长连接多用于频繁通信，数据库连接采用长连接。
58. 一个客户端口只有2个^16，理论上只有65536个长连接（0~65535）
59. 转发与重定向的区别
60. ① 转发是服务器端的跳转，重定向是客户端的跳转
61. ② 转发请求一次，请求域中的数据不会丢失，重定向请求至少两次，数据不共享。
62. ③ 转发地址栏不会改变，重定向地址栏会改变。
63. ④ 转发只能跳转到本网站的资源，重定向可以跳转到任何地方URL。
64. Cookie 和 Session的区别？
65. Cookie 和 Session都是用来跟用户身份的会话方式。
66. 区别：
67. ​ ① cookie 在客户端，不安全，session 在服务器端，更安全；
68. ​ ② cookie 可设置为长时间保持，比如默认登录功能，Session 存活时间较短，客户端关闭或者 Session 超时都会失效；
69. ​ ③ 存储大小不同， 单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限；
70. ​
71. 补充：
72. cookie和session原理

• 浏览器向服务器发出请求时，服务器先会检查这个请求是否已经包含了一个sessionid；
• 如果有，服务器就按照sessionid把这个session检索出来使用；
• 如果客户端请求不包含session id，则服务器为此客户端创建一个session，并生成一个sessionid存放到cookie中，然后响应给客户端；
• 之后，浏览器端每次请求时，都会带着这个sessionid。

禁用cookie后，还能用session吗？把 sessionID 直接写到 URL 里传上去就可以了。

1. 分布式session解决方案
2. 分布式Session的一致性问题：同一个客户端的不同请求可能会分配到不同的服务器上，如果不同的web服务器如果使用不同的Session，那么之前的状态就会丢失；

• session绑定：对客户端和服务器进行绑定（基于nginx的ip-hash策略），同一个客户端无论发送多少次请求，都被同一个服务器处理（负载不均衡）；
• session同步 ：任何一个服务器上的session发生改变（增删改），都会广播给所有其它服务器（数据量大时，服务器压力大）；
• session持久化到MySQL数据库，拿出一个数据库，专门用来存储session信息，数据库压力大；
• session持久化到redis中；

1. 补充：Nginx负载均衡的策略？
2. ① 轮询：把请求按照时间顺序依次分配到不同的服务上；
3. ② 加权：weight值越大的服务器，被分配到请求的概率越大；
4. ③ ip_hash：将客户端的ip进行hash，再通过hash值选择服务器；
5. ④ url_hash：对请求url进行hash，再通过hash值选择服务器；
6. ⑤ 响应时间：按服务器的响应时间来分配请求，响应时间短的优先分配。
7. ​
8. ​

DNS

1. www.baidu.com哪个是根域名，顶级域名，权威域名?

• 根域名：一般被省略，如果要表示根域，应该像 www.baidu.com. 在域名的最后再加上一个句点
• 顶级域名(一级域名)：由根域名管理，比如 .com 、.org 、 .cn
• 权威域名：baidu
• www是主机名
• 二级域名：是在一级域名前加一级，示例：baidu.com
• ​

1. DNS 的解析过程？
2. ① 浏览器搜索自己的DNS缓存② 如果没有命中，则读取操作系统的hosts文件看是否存在对应的映射关系③ 如果没有，则查找本地DNS服务器，查找成功则返回结果；
3. ④否则，若本地DNS服务器开启转发模式，则向上一级请求，若上一级也不能解析就找上上一级依次类推，最终把解析返回给本地DNS，本地DNS返回给主机
4. ⑤若没有开启转发模式，就把请求发至根DNS，根DNS服务器会返回对应的顶级DNS的IP，然后本地DNS服务器会向顶级DNS服务器发出查询请求，这样一直查下去，即依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终本地DNS服务器得到ip
5. ⑥ 本地域名服务器将得到的IP地址返回给操作系统，操作系统返回给浏览器，同时进行缓存​
6. DNS使用什么协议
7. 主要使用UDP，当报文长度超过512字节时使用TCP
8. ​
9. ​
10. ​

网络安全

1. 对称加密和非对称加密？
2. 对称加密：
3. 通信双方使用相同的密钥进行加密、解密。加密速度快，但是不安全。常见的对称加密有AES和DES算法。
4. 非对称加密：
5. 它需要生成两个密钥，公钥和私钥。公钥是对外公开的，而私钥是自己保管的。公钥负责加密，私钥负责解密；或者私钥负责加密，公钥负责解密。安全性更高，但是计算量大，加密和解密都很慢。常见的非对称算法有RSA和DSA。
6. ​
7. SYN攻击

• 原理
• SYN洪泛攻击（发生在传输层），利用TCP协议的特点，攻击者一直发送SYN包（三次握手的第一个数据包），而不进行再确认，那这个TCP连接在服务端就处于挂起状态，服务器收不到再确认的话，会重复发送ACK给攻击者。这样浪费服务器的大量资源。
• 防御
• ​降低SYN timeout时间，使得主机尽快释放半连接的占用；
• ​设置SYN cookie，如果短时间内收到了某个IP的重复SYN请求，就认为受到了攻击，合理地采用防火墙进行拦截

1. ​
2. ​

TCP/IP/UDP

1. 四层、五层、七层参考模型
2. ​

• 应用层：为应用程序提供交互服务。协议：DNS、HTTP、SMTP等。
• 表示层：数据格式转换、加密解密以及压缩解压缩。协议：JPEG、ASCll等
• 会话层：建立、管理、终止会话。协议：ASP；
• 传输层：负责两台主机进程间的通信，即端到端的通信。协议：TCP、UDP。
• 网络层：转发，路由选择。协议：IP、ICMP、ARP、RARP。
• 数据链路层：将网络层的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。协议：PPP、HDLC.
• 物理层：在物理媒介上实现比特流的透明传输。协议：802.3、Rj45.

1. ​
2. TCP三次握手目的、过程及状态转换
3. 目的：确认通信双方的发送与接收能力是否正常
4. 过程：
5. ​
6. ​ 假设客户端是发送端。开始时，客户端和服务端都是Closed状态，发送连接请求前，服务端会进入LISTEN状态。

• 第一次握手：客户端向服务端发送建立连接请求，发送的字段中标志位SYN=1，序列号seq=x。第一次握手前客户端的状态为CLOSE，第一次握手后客户端的状态为SYN-SENT （同步已发送）。
• 第二次握手：服务端在收到客户端发来的报文后，会为TCP连接分配缓存和变量，然后返回确认报文，其中标志位SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。第二次握手后服务端的状态为SYN-RCVD（同步收到）。（其中SYN=1表示要和客户端建立一个连接，ACK=1表示确认序号有效）
• 第三次握手：客户端在收到服务端的报文后，会为TCP连接分配缓存和变量，然后再向服务端发送报文，其中标志位ACK=1，序列号seq=x+1，确认号ack=y+1。第三次握手前客户端的状态为SYN-SENT，第三次握手后客户端和服务端的状态都为ESTABLISHED。此时连接建立完成。
• ​

1. 为啥要三次握手，为何不能是两次或四次
2. ​ 第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
3. ​ 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；
4. ​ 第三次握手：Server 额外确认了：自己发送正常，对方接收正常

• 为何不是两次：
• 确保通信双方的收发能力正常；
• 此外可以防止已失效的连接请求又传送到服务端，因而产生错误；

1. 若建立连接只需两次握手，服务端在收到连接请求后就进入ESTABLISHED状态。如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，然后连接成功，双方开始通信，通信结束后释放连接。如果那个失效的连接请求此时抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待客户端发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。

• 为何不是四次：浪费
• ​

1. 第一次握手、第二次握手、第三次握手数据丢了，分别会发生什么？
2. ​ 第一次客户端发的 SYN 丢了：客户端迟迟接不到响应，超时重传。​ 第二次服务端发的 SYN 和 ACK 丢了：客户端迟迟接不到响应，超时重传​ 第三次客户端发的 ACK 丢了：服务端超时重传
3. ​ （默认重发五次，之后自动关闭连接）
4. ​
5. 如果已经建立了连接，但客户端出现了故障怎么办？
6. 服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就就关闭连接。
7. ​
8. 第一次握手有没有数据？
9. 没有，第一次、第二次都没有数据，第三次可以携带数据。
10. ​
11. 四次挥手
12. 以客户端发起关闭连接为例，挥手前客户端和服务端均处于ESTABLISHED 状态。

• 第一次挥手：客户端向服务端发出连接释放请求，即FIN报文，然后客户端进入FIN-WAIT-1（终止等待1）状态。
• 第二次挥手：服务端收到连接释放报文后，发出ACK应答报文，服务端进入CLOSE-WAIT（关闭等待）状态。客户端收到服务端的ACK报文后，进入FIN-WAIT-2（终止等待2）状态。
• 第三次挥手： 服务端发送完数据后，会发送FIN+ACK报文，服务端进入LAST-ACK（最后确认）状态。
• 第四次挥手：客户端收到服务端的连接释放报文后，发出ACK确认报文，客户端进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过2MSL（最大报文段生存时间）后，客户端才进入CLOSED状态。服务端在收到客户端的ACK确认报文后直接进入CLOSED状态。
• ​

1. 为什么关闭的时候是四次握手？
2. 当服务端端收到客户端的连接释放报文时，服务端可能还有数据要发送给客户端，TCP要询问应用程序，为了不让客户端干等，所以只能先回复一个ACK报文。只有等到服务端所有的报文都发送完了，才能发送连接释放报文，之后两边才会真正的断开连接。
3. ​
4. 第四次挥手为什么要等待2MSL？

• 保证客户端发送的最后一个ACK报文段能够到达服务端。如果ACK报文丢失，服务端就会超时重传FIN报文，最坏情况下：去时ACK报文的最大存活时间 + 来时FIN报文的最大存活时间。即如果服务端没有收到客户端的最后ACK报文，那么客户端会在2MSL内收到服务端的重传报文，然后客户端进行重传。若A发送完ACK报文段后立即释放连接，则无法收到B重传的连接释放报文段，所以不会再发送一次确认报文段，B就无法正常进入到CLOSED状态。
• 防止已失效的报文出现在新的连接中。客户端等待2MSL，可以使当前连接所产生的所有报文都从网络中消失，使下一个新的连接中不会出现旧的连接请求报文。

1. ​
2. TCP和UDP的区别
3. ① TCP面向连接;UDP是无连接的
4. ② TCP提供可靠的服务；UDP尽最大努力交付，不保证可靠交付
5. ③ TCP面向字节流；UDP是面向报文的
6. ④ TCP有拥塞控制；UDP没有拥塞控制，网络拥塞不会使源主机的发送速率降低
7. ⑤ 一个TCP连接只能是点到点的; UDP一对多
8. ​
9. TCP和UDP的应用场景？
10. TCP：电子邮件、文件传输，准确性要求高的场景
11. UDP：在线视频、语音电话，实时性要求高，偶尔的卡顿也可以接受；
12. ​
13. TCP是如何保证可靠传输的？
14. 基础是滑动窗口协议，配合着一些控制机制使得整个传输过程可靠。
15. 滑动窗口协议：

• 首先在发送方和接收方都维护一个滑动窗口，发送方的窗口大小其实是由接收方的响应报文里的一个字段控制的。
• 发送方：窗内都允许被发送，窗内最前面的字节如果已发送并且被确认，窗口向后滑动，直到第一个未被确认状态的字节。
• 接收方：窗内都允许被接收，窗内最前的字节如果已接收，向后滑动，直到第一个不是已接收的状态的字节。最重要的是，接收方仅对最后一个按序到达的字节进行确认！

1. ​
2. 基本的控制：

• TCP会把应用层的数据拆分成适合传输的一个个块儿。
• 发送端对发送的包进行编号，接收端对收到的包进行排序。

1. 发送端的控制：
2. 超时重传：当发送方发送一个包时，启动一个定时器，等待接收方确认这个包，如果时间到了未收到确认，则重发。
3. 流量控制：为了控制发送方发送速率，保证接收方来得及接收。接收端返回的确认报文中的窗口字段可以控制发送窗口大小，从而影响发送方的速率。将窗口字段设置为 0，则不能发送数据。
4. 拥塞控制（四个算法）：当网络拥塞时，会丢包，此时发送方会不断尝试重传，从而导致拥塞程度更高。因此当出现拥塞时，应当限制发送方的发送速率。//和流量控制很像但目的不同。流量控制更多的是一个端到端的控制，要做的是抑制发送端发送数据的速率，主要是为了控制接收方来得及接。而拥塞控制是为了宏观上降低网络的拥塞程度。
5. 接收端的控制：

• 校验和：如果发现首部数据的校验和有误，那么就丢弃该数据包，且不发送确认消息。
• 丢弃重复：如果收到重复的数据包，直接丢弃。

1. 补充：
2. 拥塞控制四个算法：慢开始，拥塞避免；快重传，快恢复；
3. ​ 慢开始：每接受一个ACK确认，拥塞窗口就增加一倍，即传输的数据量增加一倍；
4. ​ 拥塞避免：当拥塞窗口超过阈值时，拥塞窗口就加一；
5. ​ 快重传：如果发送方收到重复的三个确认，则会立即重传确认所期待的下一个报文
6. ​ 快恢复：在快重传的情况下，将cwnd设置为阈值的一半进行数据传输；
7. ​
8. 如何将UDP设计成可靠的？
9. 要从 UDP 的缺点来考虑： UDP 只管发，不管收，收到的包可能不完整、乱序到达或者丢失。从以下几个方面来考虑：
10. ① 保证数据包的完整性 –> 加上验证字段② 发送的包有可能是乱序到达的 –> 每个包加上一个序号③ 可能会发生丢包 –> 需要确认和重传机制
11. ​
12. ​
13. ​
14. 粘包和拆包，解决方案？

• 粘包：
• 由于TCP是面向字节流的，字节流没有边界，可能会出现多个数据的流连到一起的情况。比如使用了Nagle算法，将多个较小的数据合并到一个包中发送；
• 拆包：
• ​TCP的字节流没有长度限制，但是网络层的IP数据包有长度限制，如果字节流过长，网络层会把这个字节流拆分到不同的包中；

1. 解决方案：
2. ​ 通过分隔符表示数据的结束；
3. ​ 在数据报头部标明数据报的长度；
4. ​
5. 三次握手如果只发生两次，那么哪些场景下也是可以接受的？
6. 文件上传（单向传输）
7. ​
8. ​
9. ​
10. ​
11. ​
12. ​

综合

1. 浏览器中输入URL返回页面过程？
2. ① DNS解析域名，得到服务器 IP。
3. ② 进行ARP解析，根据IP获取MAC地址。
4. ③ 经过三次握手，建立 TCP 连接。
5. ④ 建立 TCP 连接后，浏览器向服务器发起HTTP或HTTPs请求。
6. ⑤ 服务器处理请求，SpringMVC处理，返回渲染页面
7. ⑥ 四次挥手断开TCP连接
8. ​
9. URL个字段的含义？
10. ​
11. URI和URL
12. ​ URI：统一资源标识符，是一种抽象概念，不管用什么方法，能定位到指定的资源就行；
13. ​ URL：统一资源定位符，表示资源的路径，属于URI的子集，可以看成是URI的实现。
14. ​
15. 网关：是网络的出口，通过网关能到达其它的网络；（当前网络中能到达尽量多其他网络的设备）
16. ​
17. ​ARP解析原理
18. 根据IP地址获取目标的MAC地址；
19. 假设有A、B主机，A想要获取B的MAC地址
20. ​ ARP请求：A先检查ARP缓存表（IP与MAC地址的映射表），若没有，则通过发送广播报文来获取
21. ​ ARP应答：其它主机收到广播报文后，会首先进行ARP缓存，然后检查目的IP是不是自己，不是则丢弃报文，如果目的IP是自己，则向A单播自己的ARP应答报文；
22. ​
23. ​
24. ​