计算机网络 - 技术栈

1.OSI、TCP/IP、五层体系结构

（1）三种比较

（2）七层结构细节

（3）每一层对应的设备

2.TCP/IP协议簇

应用层（它是计算机用户，以及各种应用程序和网络之间的接口，其功能是直接向用户提供服务，完成用户希望在网络上完成的各种工作。）
传输层（向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输。传输层的作用是向高层屏蔽下层数据通信的细节，即向用户透明地传送报文。）
网络层（通过路由选择算法，为报文或分组通过通信子网选择最适当的路径。）
链路层（通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。）

3.TCP三次握手四次挥手

|----|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| | 三次握手 | 四次挥手 |
| 图示 | | |
| 详情 | 握手过程可以由客户端调用socket开启，客户端发送SYN和Seq，closed状态变换为SYN_SEND状态，服务器端由LISTEN状态变换为SYN_RECV状态，服务端回送SYN+ACK，客户端接收，客户端状态变为Established，客户端发送ACK，服务端接收到ACK，状态变为Established，至此，TCP三次握手的过程就完成了。（1）第一次握手：服务端确定（服务端可以接收数据，客户端可以发送数据）（2）第二次握手：客户端确定（服务端可以发送数据，服务端可以接收数据）（3）第三次握手：服务端确定（客户端可以接收数据）以上，（1）（2）（3）是的双方确定彼此可以接收和发送数据。 | * 关闭连接的过程可以由服务端和客户端的任何一方发起，发起的一方状态变化为： Established------>FIN_WAIT_1------>FIN_WAIT_2------>TIME_WAIT------>CLOSED; * 被动关闭的一方的状态变化为： Establised------>CLOSE_WAIT------>LAST_ACK------>CLOSED. |
| 目的 | 三次握手的目的是为了建立可靠的通信信道，简单地来说就是双方确认自己与对方的发送和接收是正常的。 这是防止已失效的连接请求报文段突然又传送到了B而引发错误。 举例，客户端A向服务端B发送数据，受到网络状态的影响，可能A发送的数据B很久以后才收到（实际上A已经通过重传机制重新发送了），当这个阻塞的数据到来的时候，B就会误以为这是一个新的连接，则B将等待A，但是实际上A并没有发起新的请求，这就导致了资源的浪费。 | TCP通信是一个双工通信，在结束连接的时候FIN和ACK是分开发送的，A向B发送FIN仅仅表示A不在发送数据，并不表示自己不在接收数据，同理，B向A发送FIN仅仅表示B不在发送数据，但是自己是可以接收数据的。为什么要在发起端加上TIME_WAIT？是为了保证ACK丢失的时候可以重传。客户端发送第四次挥手中的报文后，再经过2MSL，可使本次TCP连接中的所有报文全部消失，不会出现在下一个TCP连接中。考虑丢包问题，如果第四挥手发送的报文在传输过程中丢失了，那么服务端没收到确认ack报文就会重发第三次挥手的报文。如果客户端发送完第四次挥手的确认报文后直接关闭，而这次报文又恰好丢失，则会造成服务端无法正常关闭。 |

5.TCP在三次握手的过程中超时重传

(1) 如果第一个包，A发送给B请求建立连接的报文(SYN)如果丢掉了，A会周期性的超时重传，直到B发出确认(SYN+ACK)；

(2) 如果第二个包，B发送给A的确认报文(SYN+ACK)如果丢掉了，B会周期性的超时重传，直到A发出确认(ACK)；

(3) 如果第三个包，A发送给B的确认报文(ACK)如果丢掉了，

A在发送完确认报文之后，单方面会进入ESTABLISHED的状态，B还是SYN_RCVD状态
如果此时双方都没有数据需要发送，B会周期性的超时发送(SYN+ACK)，直到收到A的确认报文(ACK)，此时B也进入ESTABLISHED状态，双方可以发送数据；
如果A有数据发送，A发送的是(ACK+DATA)，B会在收到这个数据包的时候自动切换到ESTABLISHED状态，并接受数据(DATA)；
如果这个时候B要发送数据，B是发送不了数据的，会周期性的超时重传(SYN+ACK)直到收到A的确认(ACK)B才能发送数据。

7.在浏览器地址栏输入一个url到浏览器返回页面的过程？

浏览器分析超链指向页面的 URL。
浏览器向 DNS 请求解析 www.tsinghua.edu.cn 的 IP 地址。
域名系统 DNS 解析出清华大学服务器的 IP 地址。
浏览器与服务器建立 TCP 连接
浏览器发出取文件命令：GET /chn/yxsz/index.htm。(HTTP)
服务器给出响应，把文件 index.htm 发给浏览器。
TCP 连接释放。
浏览器显示"清华大学院系设置"文件 index.htm 中的所有文本。

可以参考：浅谈API网关

8.说一说在三次握手的时候可能存在的安全问题？

当第二次握手后，服务端将会进入SYN_RECV状态（又叫做半连接状态），通过伪造客户端的地址，这个时候服务器端一直在等待客户端返回ACK，但是由于地址是伪造的，所以根本就无法收到ACK。当这种伪造的连接数量大的时候就会导致DDOS。

9.域名解析

m.xyz.com需要查找y.abc.com的IP地址：

主机m.xyz.com向本地域名服务器进行递归查询。
本地域名服务器迭代查询，先向一个根域名服务器查询。
根域名服务器告诉本地域名服务器，下一步应该向顶级域名服务器dns.com查询。
顶级域名服务器dns.com告诉本地域名服务器，下一步查找权限域名服务器：dns.adc.com。
本地域名服务器向权限域名服务器发起查询。权限域名服务器告诉本地服务器所需的IP地址，本地服务器在告诉给本地主机。

|--------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------|
| 主机向本地域名服务器查询时一般使用递归查询 | 本地域名服务器向其他根域名服务器进行查询的时一般使用迭代查询 |
| * 递归查询：就是如果本地域名服务器没有所需域名的IP地址，本地域名服务器就以客户的方式向其他根域名服务器继续查询，而不是主机自己进行查询。返回给客户的是解析好的ip。（查查查，一直查到了再返回） | * 迭代查询： 当某个根域名服务器收到本地域名服务器的请求报文时，要么告诉它所需域名的IP地址，要么告诉它下一步应该向哪个服务器发起询问。然后让本地域名服务器自己去查询。（查不到，你去别的地方查询吧） |

根：美国（10），日本（1），英国（1），瑞士（1）

顶级域名：com，org，edu，gov等

DNS资源记录：

SOA，每一个区在开始处都包含一个授权记录
NS资源记录，域名服务器记录
A资源记录
PTR资源记录
CNAME资源记录，别名记录

10.TCP可靠传输

(分编校丢流拥重超)

|--------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 序号 | 解释 |
| 1 | 应用数据被TCP分割成为适合发送的数据块 |
| 2 | TCP将会给每一个包进行编号，接收方会对数据进行排序，将有序的数据传输给应用层。序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。 |
| 3 | TCP将会保持首部和数据的校验和，目的是检查数据在传输的过程中是否被修改 |
| 4 | 丢弃重复发送的数据 |
| 5 | 流量控制：TCP连接的每一方都有一个固定的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能够容纳的数据，当接收方来不及处理的时候，能够提示发送端降低发送的速率，防止丢包。（TCP使用的是滑动窗口进行流量控制)，如果发送端发送的数据太快，接收端来不及接收就会出现丢包问题。为了解决这个问题，TCP协议利用了滑动窗口进行了流量控制。在TCP首部有一个16位字段大小的窗口，窗口的大小就是接收端接收数据缓冲区的剩余大小。接收端会在收到数据包后发送ACK报文时，将自己的窗口大小填入ACK中，发送方会根据ACK报文中的窗口大小进而控制发送速度。如果窗口大小为零，发送方会停止发送数据。 |
| 6 | 拥塞控制（当网络阻塞的时候，减少数据的发送，拥塞控制就是防止过多的数据注入到网络中，这样使网络中的路由器或者链路不至于过载。）这里的发送方会维护一个拥塞窗口的状态变量，它和流量控制的滑动窗口是不一样的，滑动窗口是根据接收方数据缓冲区大小确定的，而拥塞窗口是根据网络的拥塞情况动态确定的，一般来说发送方真实的发送窗口为滑动窗口和拥塞窗口中的最小值。 |
| 7 | 自动重传（为了实现可靠的传输，每发送完一个分组就会停止发送，等待对方确认，确认后再发送下一个分组。） |
| 8 | 超时重传（当TCP发出一个分组后，它将启动一个定时器，等待目的端确认接收，如果不及时，将会重传。） |

11.TCP和UDP之间的区别？(面头流速可有界)

|-----------|--------------------------------------------|---------------------------------------------------------------------------------------|
| 区别 | TCP | UDP |
| 面向连接 | 面向连接，TCP不提供广播和多播服务 | 面向无连接，UDP支持一对一、多对一、一对多、多对多的交互通信。 |
| 头部大小 | 头部至少为20个字节 | 头部为8个字节 |
| 流量控制 | 有流量控制 | 没有流量控制 |
| 速度 | TCP速度较慢 | UDP速度较快 |
| 可靠性 | 可靠传输 | 不可靠传输 |
| 有序 | 有序 | 无序 |
| 界 | TCP有界，通过字节流传输 | UDP无界，每一个包是单独传输的，发送方的UDP对应用程序交下来的报文添加首部后直接交付给IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。 |
| 适用场景 | 视频 | 文件传输 |
| 应用层协议 | * HTTP，HTTPS * SMTP（简单邮件传输协议） * POP3 * SSH | * DNS * Telnet * SNMP（简单网络管理协议） * IGMP（网络组管理协议） * RIP(路由信息协议) * DHCP（动态主机设置协议） |

12.post和get的区别？

|--------|--------------------------------------------------------|-----------------------------------|
| 区别 | POST | GET |
| 可见性 | 数据在url中不可见 | 参数在url中可见 |
| 长度 | 没有长度限制 | 有长度限制 |
| 编码 | application/x-www-form-urlencoded, multipart/form-data | application/x-www-form-urlencoded |
| 缓存 | 不支持 | 支持 |
| 安全性 | 相对安全 | 相对不安全 |

14.HTTPS握手的过程？

|----|-------------------------------------------------------------------------------------------------------------------------------------------|
| 序号 | 解释 |
| 1 | 客户端给出一个协议版本号 、一个客户端生成的随机数 （Client random）以及客户端支持的加密算法。（客户端发送了三件东西） |
| 2 | 服务端确认双方使用的加密算法 ，并且给出数字证书 ，以及一个随机数（server random）。（服务端发送了两件东西）（服务端将自己的公钥发给数字证书认证机构，数字证书认证机构利用自己的私钥对服务器的公钥进行数字签名，并给服务器颁发公钥证书。） |
| 3 | 客户端确认数字证书有效，然后生成一个新的随机数 ，并且使用数字证书中的公钥，加密这个随机数，将其发送给服务端。（客户端发送了一个非对称加密的随机数） |
| 4 | 服务端使用自己的私钥，获取来自客户端的加密随机数（Premaster secret）。（服务端使用非对称加密算法进行解密） |
| 5 | 客户端和服务端根据约定的加密方法，使用前面的三个随机数，生成对话密钥（session key），用来加密整个会话。（服务端使用对称密钥会话） |

|-----------------------------------------------|---------------------------------------------------|
| 对称加密 | 非对称加密 |
| DES、3DES（TripleDES）、AES、RC2、RC4、RC5和Blowfish等 | RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用） |

15.TCP头部，UDP头部比较？

|---------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
| （1）TCP头部至少由20个字节构成（最长60个），如下图： | （2）UDP头部由8个字节构成，如下图： |
| | |

17.HTTP请求，HTTP响应，字段

（1）HTTP请求

请求行：方法，url，协议版本

请求首部字段
空行（这一个空行一定存在）
内容实体

|--------|---------|-------------------------------------------------------------------------|
| 序号 | 方法 | 描述 |
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| 9 | PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新。 |

（2）HTTP响应

响应行

- 协议版本，响应状态码，原因短语

响应首部字段
空行
内容实体

（3）字段

通用头（通用头域包含请求和响应消息都支持的头域，通用头域包含缓存头部Cache-Control、Pragma及信息性头部Connection、Date、Transfer-Encoding、Update、Via）

|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 名字 | 含义 |
| Date | Date头域表示消息发送的时间，服务器响应中要包含这个头部，因为缓存在评估响应的新鲜度时要用到，其时间的描述格式由RFC822定义。例如，Date:Mon,31 Dec 2001 04:25:57 GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。 |
| Transfer-Encoding | WEB 服务器表明自己对本响应消息体（不是消息体里面的对象）作了怎样的编码，比如是否分块（chunked），例如：Transfer-Encoding: chunked |
| Pragma | Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。 |
| Connection | Connection表示是否需要持久连接。 |
| Cache-Control | Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。 |
| Upgrade | 它可以指定另一种可能完全不同的协议，如HTTP/1.1客户端可以向服务器发送一条HTTP/1.0请求，其中包含值为"HTTP/1.1"的Update头部，这样客户端就可以测试一下服务器是否也使用HTTP/1.1了。 |
| Via | 列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器，他们用什么协议（和版本）发送的请求。 |

HTTP请求头（请求头用于说明是谁或什么在发送请求、请求源于何处，或者客户端的喜好及能力。服务器可以根据请求头部给出的客户端信息，试着为客户端提供更好的响应。）

|-------------------------|-------------------------------------------------------------------------------------------------------------------------------|
| 名字 | 含义 |
| Accept | 告诉WEB服务器自己接受什么介质类型，/ 表示任何类型，type/* 表示该类型下的所有子类型，type/sub-type。 |
| Accept-Charset | 浏览器告诉服务器自己能接收的字符集。 |
| Accept-Encoding | 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）。 |
| Accept-Language | 浏览器申明自己接收的语言。语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等。 |
| Authorization | 当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时，用该头部来回应自己的身份验证信息给WEB服务器。 |
| If-Match | 如果对象的 ETag 没有改变，其实也就意味著对象没有改变，才执行请求的动作，获取文档。 |
| If-None-Match | 如果对象的 ETag 改变了，其实也就意味著对象也改变了，才执行请求的动作，获取文档。 |
| If-Modified-Since | 如果请求的对象在该头部指定的时间之后修改了，才执行请求的动作（比如返回对象），否则返回代码304，告诉浏览器该对象没有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT |
| If-Unmodified-Since | 如果请求的对象在该头部指定的时间之后没修改过，才执行请求的动作（比如返回对象）。 |
| If-Range | 浏览器告诉 WEB 服务器，如果我请求的对象没有改变，就把我缺少的部分给我，如果对象改变了，就把整个对象给我。浏览器通过发送请求对象的ETag 或者自己所知道的最后修改时间给 WEB 服务器，让其判断对象是否改变了。总是跟 Range 头部一起使用。 |
| Range | 浏览器（比如 Flashget 多线程下载时）告诉 WEB 服务器自己想取对象的哪部分。例如：Range: bytes=1173546 |
| Proxy-Authenticate | 代理服务器响应浏览器，要求其提供代理身份验证信息。 |
| Proxy-Authorization | 浏览器响应代理服务器的身份验证请求，提供自己的身份信息。 |
| Host | 客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。如Host：rss.sina.com.cn |
| Referer | 浏览器向WEB 服务器表明自己是从哪个网页URL获得点击当前请求中的网址/URL，例如：Referer：http://www.jb51.net |
| User-Agent | 浏览器表明自己的身份（是哪种浏览器）。例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 |

HTTP响应头（响应头向客户端提供一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些头部有助于客户端处理响应，并在将来发起更好的请求。）

|-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 名字 | 含义 |
| Age | 当代理服务器用自己缓存的实体去响应请求时，用该头部表明该实体从产生到现在经过多长时间了。 |
| Server | WEB 服务器表明自己是什么软件及版本等信息。例如：Server：Apache/2.0.61 (Unix) |
| Accept-Ranges | WEB服务器表明自己是否接受获取其某个实体的一部分（比如文件的一部分）的请求。bytes：表示接受，none：表示不接受。 |
| Vary | WEB服务器用该头部的内容告诉 Cache 服务器，在什么条件下才能用本响应所返回的对象响应后续的请求。假如源WEB服务器在接到第一个请求消息时，其响应消息的头部为：Content-Encoding:gzip; Vary: Content-Encoding，那么Cache服务器会分析后续请求消息的头部，检查其Accept-Encoding，是否跟先前响应的Vary头部值一致，即是否使用相同的内容编码方法，这样就可以防止Cache服务器用自己Cache里面压缩后的实体响应给不具备解压能力的浏览器。例如：Vary：Accept-Encoding。 |

HTTP实体头部（实体头部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之，实体头部可以告知接收者它在对什么进行处理。请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括信息性头部Allow、Location，内容头部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type，缓存头部Etag、Expires、Last-Modified、extension-header。）

|----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 名字 | 含义 |
| Allow | 服务器支持哪些请求方法（如GET、POST等）。 |
| Location | 表示客户应当到哪里去提取文档，用于将接收端定位到资源的位置（URL）上。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 |
| Content-Base | 解析主体中的相对URL时使用的基础URL。 |
| Content-Encoding | WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。例如：Content-Encoding：gzip |
| Content-Language | WEB 服务器告诉浏览器理解主体时最适宜使用的自然语言。 |
| Content-Length | WEB服务器告诉浏览器自己响应的对象的长度或尺寸，例如：Content-Length: 26012 |
| Content-Location | 资源实际所处的位置。 |
| Content-MD5 | 主体的MD5校验和。 |
| Content-Range | 实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content-Length表示实际传送的字节数。 |
| Content-Type | WEB 服务器告诉浏览器自己响应的对象的类型。例如：Content-Type：application/xml |
| Etag | 就是一个对象（比如URL）的标志值，就一个对象而言，比如一个html文件，如果被修改了，其Etag也会别修改，所以，ETag的作用跟Last-Modified的作用差不多，主要供WEB服务器判断一个对象是否改变了。比如前一次请求某个html文件时，获得了其 ETag，当这次又请求这个文件时，浏览器就会把先前获得ETag值发送给WEB服务器，然后WEB服务器会把这个ETag跟该文件的当前ETag进行对比，然后就知道这个文件有没有改变了。 |
| Expires | WEB服务器表明该实体将在什么时候过期，对于过期了的对象，只有在跟WEB服务器验证了其有效性后，才能用来响应客户请求。是 HTTP/1.0 的头部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT |
| Last-Modified | WEB服务器认为对象的最后修改时间，比如文件的最后修改时间，动态页面的最后产生时间等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT |

18.HTTP1.0，HTTP1.1，HTTP2.0之间的区别

|----------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------|
| HTTP1.0 | HTTP1.1 | HTTP2.0 |
| * 无法复用连接 * 对头阻塞（head of line blocking）:对于同一个tcp连接，所有的http1.0请求放入队列中，只有前一个请求的响应收到了，然后才能发送下一个请求。可见，http1.0的队首组塞发生在客户端。 | * 长连接（在头部加入了connection：keep-alive） * 管道化（将请求队列移动到服务端队列）HTTP/1.1通过pipelining管道技术实现一次性发送多个请求，以期提高吞吐和性能,可见，http1.1的队首阻塞发生在服务器端。 * 缓存机制（引入了新的字段cache-control，支持断点重传） * 增加了host字段（使得一个服务器可创建多个站点） | * 二进制分帧 * 多路复用（消息由一个帧或者多个帧组成，可以乱序进行发送，之后使用帧的stream id进行重组，二进制分帧使得多路复用成为可能，多路复用实现真正的并发） * 头部压缩，通信双方保存header filed表 * 服务器推送（不用客户端进行明确请求） |

（4）最新的HTTP版本？

Evolution of HTTP - HTTP | MDN

（5）在应用中如何配置HTTP版本？

# For HTTP, the proxy_http_version directive should be set to "1.1" and the "Connection" header field should be cleared:
upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    ...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 新HTTP1.0与HTTP1.1区别： | HTTP1.1与HTTP2.0的区别： |
| HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。主要区别主要体现在： * 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。 * 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。 * 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。 * Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。 * 长连接、持续连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。 | * 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。 * 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。 * header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。 * 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能 |

19. cookie和session

（1）cookie数据存放在客户的浏览器上，session存放在服务器上。

（2）cookie不是安全的，别人可以分析存放在本地的cookie进行cookie欺骗。

（3）session会一定时间内存放在服务器上，当访问次数增多的时候，会影响性能。

（4）单个cookie保存的数据不会超过4K，很多浏览器限制一个站点的cookie数目不超过20个。

20.HTTP状态码

（1）概括：

|-----|------------------------|---------------|
| | 类别 | 原因短语 |
| 1XX | Informational（信息状态码） | 接收的请求正在处理 |
| 2XX | Success（成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求出错 |

（2）细节

|---------|----------------- | 状态码 | 100 | Continue | 101 | Switching Protocols | | | 200 | OK | 201 | Created | 202 | Accepted | 203 | Non-Authoritative | 204 | No Content | 205 | Reset Content | 206 | Partial Content | | | 300 | Multiple Choices | 301 | Moved Permanently | 302 | Found | 303 | See Other | 304 | Not Modified | 305 | Use Proxy | 306 | Unused | 307 | Temporary Redirect | | | 400 | Bad Request | 401 | Unauthorized | 402 | Payment Required | 403 | Forbidden | 404 | Not Found | 405 | Method Not Allowed | 406 | 407 | Proxy Authentication | 408 | Request Time-out | 409 | Conflict | 410 | Gone | 411 | Length Required | 412 | Precondition Failed | 413 | Request Entity Too Large | 414 | Request-URI Too Large | 415 | Unsupported Media Type | 416 | Requested | 417 | Expectation Failed | 500 | Internal Server Error | 501 | Not Implemented | 502 | Bad Gateway | 503 | Service Unavailable | 504 | Gateway Time-out | 505 | HTTP Version not supported ----------------|--------------------------------------------------------------------------------------|
| 状态码英文名称 | 中文描述 |
| 继续。客户端应继续其请求 |
| 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| |
| 请求成功。一般用于GET与POST请求 |
| 已创建。成功请求并创建了新的资源 |
| 已接受。已经接受请求，但未处理完成 |
Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 部分内容。服务器成功处理了部分GET请求 |
| |
| 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 查看其它地址。与301类似。使用GET和POST请求查看 |
| 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 使用代理。所请求的资源必须通过代理访问 |
| 已经被废弃的HTTP状态码 |
| 临时重定向。与302类似。使用GET请求重定向 |
| |
| 客户端请求的语法错误，服务器无法理解 |
| 请求要求用户的身份认证 |
| 保留，将来使用 |
| 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 客户端请求中的方法被禁止 |
| Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 服务器等待客户端发送的请求时间过长，超时 |
| 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 客户端请求信息的先决条件错误 |
| 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 请求的URI过长（URI通常为网址），服务器无法处理 |
| 服务器无法处理请求附带的媒体格式 |
range not satisfiable | 客户端请求的范围无效 |
| 服务器无法满足Expect的请求头信息 |
| 服务器内部错误，无法完成请求 |
| 服务器不支持请求的功能，无法完成请求 |
| 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 服务器不支持请求的HTTP协议的版本，无法完成处理 |

22.TCP的拥塞控制

（重传就可能导致拥塞）

TCP通过慢启动、拥塞避免、快重传以及快恢复这四个算法来进行拥塞控制（使用滑动窗口进行流量控制）：

|----------|--------------------------------------------------------------------------------------------------------------------------|
| 策略 | 详情 |
| 慢启动 | 一开始先设置一个比较小的拥塞窗口值cwnd（报文段的倍数），然后进行数据传输，每收到一个报文段的确认，我们就将cwnd+1 ，这样下来，cwnd总体上是乘以2^n的倍数增长。（慢启动非增长速度慢，只是增长的初始基数比较小） |
| 拥塞避免 | 因为慢启动算法的增长比较快，当cwnd = ssthresh（预先设置好的门限值）时，我们启动拥塞避免算法，窗口值开始线性增长。 |
| 快重传 | 快重传的目的是为了让发送方尽早知道某个报文段的丢失。如何知道呢？当我们重复收到某一个报文段的3次确认时，我们就可以判断，它的下一个报文段可能出现了丢失。这时我们启动快重传算法，立即重传丢失的报文段。 |
| 快恢复 | 上面快重传算法的启动只是因为个别报文段的丢失，我们这时并不判断为网络拥塞，而是启动快恢复算法。我们将cwnd=ssthresh=当前cwnd的一半，并且开始拥塞避免算法。 |

随着拥塞避免算法的进行，网络出现超时的情况（这时判断为拥塞出现 ）。这时将cwnd降为一开始的值，重新进行慢开始-拥塞避免，并且此时的门限值设为出现拥塞时的cwnd的一半。

当然，也有的快恢复算法是将当前拥塞窗口再增大3个报文段的值，因为既然收到了3个重复的ACK，则说明有三个分组已经离开了网络，不在占用网络资源而是停留在对方缓存当中，可以适当将窗口值增大。

23.TCP的流量控制

滑动窗口协议

24.重传算法

|--------|---------------------------------------------------------------------------------------|
| SACK方法 | * 为了解决快速重传的缺点，一种更好的SACK重传策略被提出 * 基于快速重传，同时在tcp头里加了一个SACK的东西 * 解决了什么问题：客户端应该发送哪些超时包的问题 |

25.路由算法

（1）路由：找到任意两个节点之间开销最小的路径。

（2）距离向量，链路状态

距离向量：网络中没有任何一个节点知道整张表的信息，自己只知道它自己的路由表的内容。好处：所有的节点在没有任何集中授权的额情况下取得网络的一致视图。（RIP协议）
链路状态：每一个节点都有足够的信息构建完整的网络映象。（OSPF协议，开放最短路径优先），路由的计算采用迪杰特斯拉算法进行计算。

26.IP数据报格式

27.ABC类地址

A、B、C类IP地址的网络号字段分别是1、2、3个字节长，而在网络号的1-3位是类别位，分别是：0、10、110。
A、B、C类IP地址的主机号字段分别为3、2、1个字节。
A、B、C类IP地址是单播地址，D类IP地址（前四位为1110）为多播地址，E类IP地址（前四位1111）保留为以后使用。
A类地址的网络号中：全0和127是不指派的；主机号中：全0代表本主机所连接的单个网络地址，全1代表网络上的所有主机，也是不指派的。
B类IP地址网络号中：128.0.0.0不指派；主机号中：全0和全1也不指派。
C类IP地址网络号中：192.0.0.0不指派；主机号中：全0和全1也不指派。

28.端口号

|-------|-----|--------|------|-----|------|------|------|------------|-------|
| 应用程序 | FTP | TELNET | SMTP | DNS | TFTP | HTTP | SNMP | SNMP(trap) | HTTPS |
| 熟知端口号 | 21 | 23 | 25 | 53 | 69 | 80 | 161 | 162 | 443 |

29.滑动窗口

（解决的是速率不匹配问题）

解决了什么问题：发送方和接收方速率不匹配时，保证可靠传输和包乱序的问题
机制：接收方根据目前缓冲区大小，通知发送方目前能接收的最大值。发送方根据接收方的处理能力来发送数据。通过这种协调机制，防止接收端处理不过来。
窗口大小：接收方发给发送端的这个值称为窗口大小

30.拥塞窗口

（控制的是发送方）

解决什么问题：发送方发送速度过快，导致中转路由器拥堵的问题
机制：发送方增加一个拥塞窗口（cwnd），每次受到ack，窗口值加1。发送时，取拥塞窗口和接收方发来的窗口大小取最小值发送
起到发送方流量控制的作用

33.同源策略

|---------------------------------------------------|----|----------------------------|
| URL | 结果 | 原因 |
| http://store.company.com/dir2/other.html | 成功 | 只有路径不同 |
| http://store.company.com/dir/inner/another.html | 成功 | 只有路径不同 |
| https://store.company.com/secure.html | 失败 | 不同协议 ( https和http ) |
| http://store.company.com:81/dir/etc.html | 失败 | 不同端口 ( http:// 80是默认的) |
| http://news.company.com/dir/other.html | 失败 | 不同域名 ( news和store ) |

34.跨域问题

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。

CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）

1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）

3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

35. websocket和SSE的区别

|----------------------------------------------------------|----------------------------------------------------|
| websocket | SSE |
| Websocket是区别于HTTP的另外一种协议，是全双工通信，协议相对来说比较中，对代码侵入度比较高。 | SSE是标准的HTTP协议，是半双工通信，支持断线重连和自定义事件和数据类型，相对轻便灵活。 |

36. epoll

|---------------------------------------------------------------------------------------------------|-----------------------------------------|
| | * epoll_create * epoll_ctl * epoll_wait |