第10章：网络——一、HTTP协议；二、HTTPS与网络安全；三、TCP/UDP；四、DNS解析；五、Session/Cookie

一、HTTP协议

     1、你是怎么理解HTTP的？HTTP具体包含哪些内容？

HTTP是超文本传输协议，主要包含三部分内容：请求/响应报文，链接建立流程，HTTP的特点。

     2、请求/响应报文

请求报文由请求行、header、报文内容组成。请求行包括方法、URL、协议版本。header由多个key/value组成。

响应报文由响应行、header、报文内容组成。响应行包括版本、状态码、短语(即状态码说明)。header由多个key/value组成。

     3、GET、POST方式的区别

GET用于获取资源，是安全的、幂等的、可缓存的。

POST用于处理资源，是非安全的、非幂等的、不可缓存的。

此处的安全指：不引起Server端任何状态变化。

此处的幂等指：同一个请求方法执行多次和执行一次的效果完全相同。

此处的可缓存指：请求是否可以被缓存。

     4、常见状态码的含义(初级工程师考察)

2xx代表响应成功

3xx代表发生了网络重定向

4xx代表客户端发起的请求存在问题

5xx代表服务端存在问题

     5、链接建立/断开流程

     6、HTTP的特点

无连接：每次使用需要建立连接，使用完成后需要断开连接。可以通过HTTP的持久连接来优化。

无状态：Server并不知道是谁发送的请求。可以通过Session/Cookie解决。

     7、持久连接

1）、持久连接相关头部字段

     Connection:keep-alive代表客户端期望使用持久连接

     time:20代表持久连接持续多少秒，在该段时间内相同域名的请求可以使用该连接。

     max:10代表该持久连接最多可以发生多少次请求

2）、持久连接中如何判断一个请求是否结束？

     有两种方案，一是，通过响应头中的Content-length字段标识响应报文的长度，接受该长度的数据则请求结束；二是，通过chunked字段，有些比较长的响应报文是分片到达的，如果是结束报文则chunked字段为空。此处我的疑问是分片的报文无序到达时chunked怎么知道呢？？？

     8、Charles(查尔斯)抓包原理？

利用中间人攻击原理实现的。

二、HTTPS与网络安全

     1、HTTPS和HTTP的区别？

HTTPS= HTTP+SSL/TLS。SSL/TLS准确的说是应用层协议，但是位于HTTP下面，包装了HTTP请求，保证了请求安全。

HTTP在传输数据时使用的是明文，不安全，为了解决这一隐患推出了基于HTTP之下TCP之上的SSL安全套接字协议层，SSL是基于HTTP标准并对TCP传输数据时进行加密，所以HPPTS是HTTP+SSL/TCP的简称。由于HTTPS的推出受到了很多人的欢迎，在SSL更新到3.0时，IETF对SSL3.0进行了标准化，并添加了少数机制(但是几乎和SSL3.0无差异)，标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传输层协议)，可以说TLS就是SSL的新版本3.1，并同时发布“RFC2246-TLS加密协议详解”，如果想更深层次的了解TLS的工作原理可以去RFC的官方网站：www.rfc-editor.org，搜索RFC2246即可找到RFC文档！ 
原文链接：https://blog.csdn.net/enweitech/article/details/81781405

     2、HTTPS连接建立流程是怎样的？

HTTPS连接建立流程并非没有三次握手、四次挥手，实际上HTTPS连接建立流程是在三次握手成功后进行的，因为TCP是TLS的底层协议，TLS的报文到到TCP后是需要包装成TCP报文的。

会话秘钥=randomS+randomC+预主秘钥，用于后续通信中的对称加密。更详细的TLS介绍参考https://www.cnblogs.com/zhuqil/archive/2012/10/06/ssl_detail.html和HTTPS权威指南。RSA加密最好也详细看看。

     3、HTTPS连接建立流程中使用了哪些加密手段？为什么采用这些加密手段。

连接建立过程使用非对称加密，非对称加密由于加密和解密采用的手段不一样，所以很耗时。所以后续通信过程使用对称加密。

     4、非对称加密

     5、对称加密

缺点：容易发生秘钥劫持，不安全。

 

三、TCP/UDP

     TCP称为传输控制协议，UDP称为用户数据报协议。

     1、UDP特点

无连接、尽最大努力交付、面向报文。面向报文可以理解为：既不合并，也不拆分。也就是说应用层报文不管大小，传递到UDP层时UDP层只管在应用层报文的基础上封装头部。如果UDP报文中的数据过大，则IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃。 参考网址https://blog.csdn.net/caoshangpa/article/details/51530685。===我理解了UDP是面向报文的意思：UDP层报文不分片、不缓冲；而TCP层拥有缓冲区，应用层的数据先放到缓冲区中，TCP层控制缓冲区的数据发送，且控制报文大小，所以TCP缓冲区中的数据被连续发送，像是数据流，所以TCP是面向字节流的。

     2、UDP功能

复用、分用、差错检测。UDP报文格式如下：

UDP差错检测需要额外拼装12字节伪首部，然后是8字节UDP首部，然后是7字节数据。接收端收到UDP数据报后重新计算首部的检验和，如果一致则说明无差错。这就是UDP进行的简单的差错检测。

     3、TCP特点

面向连接、可靠传输、面向字节流、流量控制、拥塞控制。

1）、面向连接

     数据传输之前需要通过三次握手建立连接，数据传输结束之后需要通过四次挥手释放连接。

2）、为什么需要进行三次握手？

     如果客户端发送建立连接的SYN请求在网络传输过程中发生了超时，那么客户端会启用超时重传功能，服务端收到重传的报文之后会回复给客户端一个确认报文。如果是两次握手，此时连接已经建立了，但是如果超时的SYN请求此时到达了服务端，此时服务端会认为客户端要建立一个新的连接，实际上客户端并没有建立两个连接，此时就需要三次握手来解决这个问题：服务端收到超时的SYN报文后会向客户端发送确认报文，但是过了一段时间收不到客户端的确认报文，服务端会认为这是一个超时报文。

3）、为什么要四次挥手？

     因为TCP连接是全双工的，需要关闭四个方向的通信。

4）、可靠传输

     无差错、不丢失、不重复、按序到达。以上四点通过超时等待协议实现，可以从四方面来理解这个协议：无差错情况、超时重传、确认丢失、确认迟到。

5）、面向字节流

     我理解了UDP是面向报文的意思：UDP层报文不分片、不缓冲；而TCP层拥有缓冲区，应用层的数据先放到缓冲区中，TCP层控制缓冲区的数据发送，且控制报文大小，所以不管应用层怎么将数据传递给TCP层，TCP层会控制TCP缓冲区中的数据按TCP层规定的大小被连续发送，像是数据流，所以TCP是面向字节流的。

6）、流量控制==面试难点

     所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受，解决发送端与接收方吞吐量不匹配的问题，目的是让发送端根据接收端的接收能力动态的调整发送速率。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。参考https://www.cnblogs.com/gaopeng527/p/5255757.html。https://blog.csdn.net/a298804870/article/details/53512385和https://blog.csdn.net/sicofield/article/details/9708311和https://www.cnblogs.com/wxgblogs/p/5616829.html可以帮助理解。

     TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。如果没有这些“窗口”，那么TCP没发送一段数据后都必须等到接收端确认后才能发送下一段数据，这样做的话TCP传输的效率实在是太低了。解决的办法就是在发送端等待确认的时候继续发送数据，假设发送到第X个数据段时收到接收端的确认信息，如果X在可接受的范围内那么这样做也是可接受的。这就是窗口（缓冲区）引入的缘由。

     接收端窗口大小为rwnd(接收端将此窗口值放在 TCP 报文的首部中的窗口字段，传送给发送端)，拥塞窗口(cwnd)指当前网络拥塞状况下允许的窗口大小 ,发送窗口大小为swnd，发送窗口的上限值 = Min [rwnd, cwnd]。当 rwnd < cwnd 时，是接收端的接收能力限制发送窗口的最大值。当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值。 

     下面用两个图来说明滑动窗口协议：

     第一个图说明发送端已发送了 400 字节的数据，但只收到对前 200 字节数据的确认，同时窗口大小不变。还可发送 300 字节。第二个图说明发送端收到了对方对前 400 字节数据的确认，但对方通知发送端必须把窗口减小到 400 字节。现在发送端最多还可发送 400 字节的数据。

     基于滑动窗口协议(按序到达也是通过该协议实现)实现。什么是滑动窗口协议、你是怎样理解滑动窗口协议的？这是新浪的三面。讲解如下图：     

7）、拥塞控制。

     主要有“慢开始、拥塞避免”、“快恢复、快重传”两种策略。“慢开始、拥塞避免”策略参考https://www.cnblogs.com/gaopeng527/p/5255757.html。

     慢开始原理如下：

      （1）在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS(最大报文段长度) 的数值。

      （2）在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 的数值。

      （3）用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。

     请简单描述TCP慢启动特点？这道题其实说的就是“慢开始、拥塞避免”策略，具体如下图：

                                                          注：图中窗口的单位都是报文段

      （1）当 TCP 连接进行初始化时：发送窗口：swnd = 1 ，慢开始阈值：ssthresh = 16

      （2）发送端收到 ACK1 （确认 M0，期望收到 M1）后，将 cwnd 从 1 增大到 2，于是发送端可以接着发送 M1 和 M2 两个报文段（指数增长）

      （3）接收端发回 ACK2 和 ACK3。发送端每收到一个对新报文段的确认 ACK，就把发送端的拥塞窗口加 1。现在发送端的 cwnd 从 2 增大到 4，并可发送 M4 ~ M6共 4个报文段。（指数增长）

      （4）当cwnd >= ssthresh，cwnd执行拥塞避免算法，cwnd窗口按线性规律增长。 （加法增大）

      （5）当发送 超时，此时swnd = 24 ：ssthresh = swnd/2 = 12；（乘法减小），swnd = 1

      （6）重复地2步。

     快重传：发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了，就应立即重传丢失的报文段而不必继续等待为该报文段设置的重传计时器的超时。参考https://blog.csdn.net/wo16fafafa/article/details/52317050。

     快恢复说明如下：

      （1) 当发送端收到连续三个重复的 ACK 时，就重新设置慢开始门限 ssthresh。

      （2) 与慢开始不同之处是 swnd 不是设置为 1，而是设置为 ssthresh + 3 * MSS。 

      （3) 若收到的重复的 ACK 为 n 个（n > 3），则将 cwnd 设置为 ssthresh + n * MSS。

      （4) 若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。

      （5) 若收到了确认新的报文段的 ACK，就将 swnd 缩小到 ssthresh。

 

四、DNS解析(中高级会问)

     1、你是否了解DNS解析？DNS解析是怎样的一个过程？

DNS解析是域名到IP地址的映射，DNS解析请求采用UDP数据报，且明文。

     2、DNS解析查询方式

1）、递归查询

2）、迭代查询

     3、DNS解析存在哪些常见问题？

1）、DNS劫持问题

2）、DNS解析转发问题

     4、DNS劫持定义

     5、DNS劫持与HTTP的关系是怎样的？

没有关系。因为DNS解析发生在HTTP连接建立之前，且DNS解析请求使用UDP数据报，端口号53.

     6、怎样解决DNS劫持？

1）、httpDNS

     DNS解析是使用DNS协议向DNS服务器的53端口进行请求；而httpDNS是使用HTTP协议向DNS服务器的80端口进行请求。由于httpDNS已经不采用DNS协议，所以也就不存在劫持问题。

2）、长连接

     7、DNS解析转发

由于权威DNS的流量控制机制，转发之后获取到的就不是“xx移动DNS”对应的IP地址，这就会造成跨网访问，请求缓慢。所以一般不要用小厂商的网络，它容易去做DNS解析转发。

 

五、Session/Cookie

     Session/Cookie是对HTTP协议无状态特点的补偿。

     1、Cookie

Cookie主要用来记录用户状态，区分用户；Cookie保存在客户端。

由上图可以看出：客户端发送的Cookie在http请求报文的Cookie首部字段中；服务器设置http响应报文的Set-Cookie首部字段。

     2、怎样修改Cookie？

通过新Cookie覆盖旧Cookie来修改。覆盖规则：name、path、domain等都需要与原Cookie一致，否则不能覆盖。

     3、怎样删除Cookie？

通过新Cookie覆盖旧Cookie来删除。覆盖规则：name、path、domain等都需要与原Cookie一致，否则不能覆盖。且此时需要设置Cookie的过期时间为已过期，规则为：设置Cookie的expires=过去的一个时间点，或者maxAge=0。

     4、怎样保证Cookie的安全？

1）、对Cookie进行加密处理

     这种方式不太好，因为可以对前端加密脚本进行攻击。

2）、只在https上携带Cookie

3）、设置Cookie为httpOnly，防止跨站脚本攻击

     5、Session

Session也是用来记录用户状态，区分用户的；Session保存在服务器端。且Session需要依赖Cookie机制实现。Session工作流程如下：