搞定计算机网络的常见面试问题
在浏览器中输入一个 URL 至页面呈现，网络上都发生了什么事？
能说说 ISO 七层模型和 TCP/IP 四层模型吗？
TCP/IP 与 HTTP 有什么关系吗？
TCP 协议与 UDP 协议的区别？
请详细介绍一下 TCP 的三次握手机制，为什么要三次握手？挥手却又是四次呢？
详细讲一下 TCP 的滑动窗口？知道流量控制和拥塞控制吗？
说一下对称加密与非对称加密？
状态码 206 是什么意思？
你们用的 https 是吧，https 工作原理是什么？
.....
一、计算机网络
通信协议
通信协议（communications protocol）是指双方实体完成通信或服务所必须遵循的规则和约定。通过通信信道和设备互连起来的多个不同地理位置的数据通信系统，要使其能协同工作实现信息交换和资源共享，它们之间必须具有共同的语言。交流什么、怎样交流及何时交流，都必须遵循某种互相都能接受的规则。这个规则就是通信协议。
网络模型
随着技术的发展，计算机的应用越来越广泛，计算机之间的通信开始了百花齐放的状态，每个具有独立计算服务体系的信息技术公司都会建立自己的计算机通信规则，而这种情况会导致异构计算机之间无法通信，极大的阻碍了网络通信的发展，至此为了解决这个问题，国际标准化组织（ISO）制定了 OSI 模型，该模型定义了不同计算机互联的标准，OSI 模型把网络通信的工作分为 7 层，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
这七层模型是设计层面的概念，每一层都有固定要完成的职责和功能，分层的好处在于清晰和功能独立性，但分层过多会使层次变的更加复杂，虽然不需要实现本层的功能，但是也需要构造本层的上下文，空耗系统资源，所以在落地实施网络通信模型的时候将这七层模型简化合并为四层模型分别是应用层、传输层、网络层、网络接口层（各层之间的模型、协议统称为：TCP/IP 协议簇）。
从上图可以看到，TCP/IP 模型合并了 OSI 模型的应用层、表示层和会话层，将 OSI 模型的数据链路层和物理层合并为网络访问层。
上图还列出了各层模型对应 TCP/IP 协议栈中的协议以及各层协议之间的关系。比如 DNS 协议是建立在 TCP 和 UDP 协议的基础上，FTP、HTTP、TELNET 协议建立在 TCP 协议的基础上，NTP、TFTP、SNMP 建立在 UDP 协议的基础上，而 TCP、UDP 协议又建立在 IP 协议的基础上，以此类推….
OSI 中的层功能 TCP/IP 协议族应用层文件传输，电子邮件，文件服务，虚拟终端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，RIP，Telnet 表示层数据格式化，代码转换，数据加密无会话层控制应用程序之间会话能力；如不同软件数据分发给不同软件 ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets 传输层端到端传输数据的基本功能 TCP、UDP 网络层定义 IP 编址，定义路由功能；如不同设备的数据转发 IP，ICMP，RIP，OSPF，BGP，IGMP 数据链路层定义数据的基本格式，如何传输，如何标识 SLIP，CSLIP，PPP，ARP，RARP，MTU 物理层以二进制数据形式在物理媒体上传输数据 ISO2110，IEEE802
当我们某一个网站上不去的时候。通常会 ping 一下这个网站
ping 可以说是 ICMP 的最著名的应用，是 TCP/IP 协议的一部分。利用ping命令可以检查网络是否连通，可以很好地帮助我们分析和判定网络故障。
二、TCP/IP
数据在网络中传输最终一定是通过物理介质传输。物理介质就是把电脑连接起来的物理手段，常见的有光纤、双绞线，以及无线电波，它决定了电信号(0 和 1)的传输方式，物理介质的不同决定了电信号的传输带宽、速率、传输距离以及抗干扰性等等。网络数据传输就像快递邮寄，数据就是快件。只有路打通了，你的”快递”才能送到，因此物理介质是网络通信的基石。
寄快递首先得称重、确认体积(确认数据大小)，贵重物品还得层层包裹填充物确保安全，封装，然后填写发件地址(源主机地址)和收件地址(目标主机地址)，确认快递方式。对于偏远地区，快递不能直达，还需要中途转发。网络通信也是一样的道理，只不过把这些步骤都规定成了各种协议。
TCP/IP 的模型的每一层都需要下一层所提供的协议来完成自己的目的。我们来看下数据是怎么通过 TCP/IP 协议模型从一台主机发送到另一台主机的。
当用户通过 HTTP 协议发起一个请求，应用层、传输层、网络互联层和网络访问层的相关协议依次对该请求进行包装并携带对应的首部，最终在网络访问层生成以太网数据包，以太网数据包通过物理介质传输给对方主机，对方接收到数据包以后，然后再一层一层采用对应的协议进行拆包，最后把应用层数据交给应用程序处理。
TCP/IP 与 HTTP
TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议）是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP 协议不仅仅指的是 TCP 和 IP 两个协议，而是指一个由 FTP、SMTP、TCP、UDP、IP 等协议构成的协议簇， 只是因为在 TCP/IP 协议中 TCP 协议和 IP 协议最具代表性，所以被称为 TCP/IP 协议。
而 HTTP 是应用层协议，主要解决如何包装数据。
“IP”代表网际协议，TCP 和 UDP 使用该协议从一个网络传送数据包到另一个网络。把 IP 想像成一种高速公路，它允许其它协议在上面行驶并找到到其它电脑的出口。TCP 和 UDP 是高速公路上的“卡车”，它们携带的货物就是像 HTTP，文件传输协议 FTP 这样的协议等。
TCP 与 UDP
都属于传输层协议。
TCP（Transmission Control Protocol，传输控制协议）是面向连接的协议，也就是说，在收发数据前，必须和对方建立可靠的连接。一个 TCP 连接必须有三次握手、四次挥手。
UDP（User Data Protocol，用户数据报协议）是一个非连接的协议，传输数据之前源端和终端不建立连接， 当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上
TCPUDP 连接性面向连接面向非连接传输可靠性可靠不可靠报文面向字节流面向报文效率传输效率低传输效率高流量控制滑动窗口无拥塞控制慢开始、拥塞避免、快重传、快恢复无传输速度慢快应用场合对效率要求低，对准确性要求高或要求有连接的场景对效率要求高，对准确性要求低
TCP 和 UDP 协议的一些应用
TCP 连接的建立与终止
TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能体现在它首部中的各字段的作用。
TCP 报文段首部的前 20 个字节是固定的（下图），后面有 4n 字节是根据需要而增加的选项（n 是整数）。因此 TCP 首部的最小长度是 20 字节。
TCP 报文首部
源端口和目的端口，各占 2 个字节，分别写入源端口和目的端口；
序列号（Sequence number），占 4 字节。序号范围是【0，2^32 - 1】，共 2^32 个序号。序号增加到 2^32-1 后，下一个序号就又回到 0。TCP 是面向字节流的。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号是 301，而接待的数据共有 100 字节。这就表明：本报文段的数据的第一个字节的序号是 301，最后一个字节的序号是 400。显然，下一个报文段（如果还有的话）的数据序号应当从 401 开始，即下一个报文段的序号字段值应为 401。这个字段的序号也叫“报文段序号”;
确认号（Acknowledge number），占 4 个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B 收到了 A 发送过来的报文，其序列号字段是 501，而数据长度是 200 字节，这表明 B 正确的收到了 A 发送的到序号 700 为止的数据。因此，B 期望收到 A 的下一个数据序号是 701，于是 B 在发送给 A 的确认报文段中把确认号置为 701；
数据偏移，占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。
保留，占 6 位，保留为今后使用，但目前应置为 0；
紧急 URG（URGent），当 URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
确认 ACK（ACKnowledgment），仅当 ACK=1 时，确认号字段才有效。TCP 规定，在连接建立后所有报文的传输都必须把 ACK 置 1；
推送 PSH（PuSH） ，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将 PSH=1；
复位 RST（ReSeT），当 RST=1，表明 TCP 连接中出现严重差错，必须释放连接，然后再重新建立连接；
同步 SYN（SYNchronization），在连接建立时用来同步序号。当 SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使 SYN=1，ACK=1；
终止 FIN（FINis），用来释放连接。当 FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
窗口，占 2 字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；
检验和，占 2 字节，校验首部和数据这两部分；
紧急指针，占 2 字节，指出本报文段中的紧急数据的字节数；
选项，长度可变，定义一些其他的可选的参数
TCP 是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如 ip 地址、端口号等。
TCP 三次握手
所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送 3 个包。
三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。
第一次握手(SYN=1, seq=x)
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)
第三次握手(ACK=1，ACKnum=y+1)
为什么需要三次握手呢？两次不行吗？
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
具体例子：“已失效的连接请求报文段”的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”
TCP 四次挥手
TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作。
第一次挥手(FIN=1，seq=x)
第二次挥手(ACK=1，ACKnum=x+1)
第三次挥手(FIN=1，seq=y)
第四次挥手(ACK=1，ACKnum=y+1)
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉 Client 端，"你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。
由于 TCP 协议是全双工的，也就是说客户端和服务端都可以发起断开连接。两边各发起一次断开连接的申请，加上各自的两次确认，看起来就像执行了四次挥手。
为什么 TIME_WAIT 状态需要经过 2MSL(最大报文段生存时间)才能返回到 CLOSE 状态？
虽然按道理，四个报文都发送完毕，我们可以直接进入 CLOSE 状态了，但是我们必须假象网络是不可靠的，有可以最后一个 ACK 丢失。所以 TIME_WAIT 状态就是用来重发可能丢失的 ACK 报文。
还有一个原因，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个 2MSL 时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
TCP 协议如何来保证传输的可靠性
对于可靠性，TCP 通过以下方式进行保证：
数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
详细讲一下 TCP 的滑动窗口
滑动窗口机制
如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在 TCP 连接上实现对发送方的流量控制。
从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。
可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。
流量控制
TCP 是全双工的，客户端和服务器均可作为发送方或接收方，我们现在假设一个发送方向接收方发送数据的场景来讲解流量控制。首先我们的接收方有一块接收缓存，当数据来到时会先把数据放到缓存中，上层应用等缓存中有数据时就会到缓存中取数据。假如发送方没有限制地不断地向接收方发送数据，接收方的应用程序又没有及时把接收缓存中的数据读走，就会出现缓存溢出，数据丢失的现象，为了解决这个问题，我们引入流量控制窗口。
假设应用程序最后读走的数据序号是 lastByteRead，接收缓存中接收到的最后一个数据序号是 lastByteRcv，接收缓存的大小为 RcvSize，那么必须要满足 lastByteRcv - lastByteRead <= RcvSize 才能保证接收缓存不会溢出，所以我们定义流量窗口为接收缓存剩余的空间，也就是 Rcv = RcvSize - (lastByteRcv - lastByteRead)。只要接收方在响应 ACK 的时候把这个窗口的值带给发送方，发送方就能知道接收方的接收缓存还有多大的空间，进而设置滑动窗口的大小。
拥塞控制
拥塞控制是指发送方先设置一个小的窗口值作为发送速率，当成功发包并接收到 ACK 时，便以指数速率增大发送窗口的大小，直到遇到丢包（超时/三个冗余 ACK），才停止并调整窗口的大小。这么做能最大限度地利用带宽，又不至于让网络环境变得太过拥挤。
最终滑动窗口的值将设置为流量控制窗口和拥塞控制窗口中的较小值。
TCP 的拥塞处理
计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。拥塞控制的方法主要有以下四种：
慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;
拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。
服务器出现了大量 CLOSE_WAIT 状态如何解决
大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。
讲一讲 SYN 超时，洪泛攻击，以及解决策略
什么 SYN 是洪泛攻击？在 TCP 的三次握手机制的第一步中，客户端会向服务器发送 SYN 报文段。服务器接收到 SYN 报文段后会为该 TCP 分配缓存和变量，如果攻击分子大量地往服务器发送 SYN 报文段，服务器的连接资源终将被耗尽，导致内存溢出无法继续服务。
解决策略：当服务器接受到 SYN 报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源 Id，目的 Id，端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie，并把 cookie 作为序列号响应给客户端。
如果客户端是正常建立连接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源 Id，目的 Id，端口号以及秘密函数计算出一个结果，如果结果的值 + 1 等于确认字段的值，则证明是刚刚请求连接的客户端，这时候才为该 TCP 分配资源
这样一来就不会为恶意攻击的 SYN 报文段分配资源空间，避免了攻击。
三、HTTP
HTTP1.0、HTTP1.1、HTTP2.0 的区别
post 和 get 的区别
HTTP 全称是 HyperText Transfer Protocal，即：超文本传输协议。是互联网上应用最为广泛的一种网络通信协议，它允许将超文本标记语言（HTML）文档从 Web 服务器传送到客户端的浏览器。目前我们使用的是 HTTP/1.1 版本。所有的 WWW 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。1960 年美国人 Ted Nelson 构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext），这成为了 HTTP 超文本传输协议标准架构的发展根基。
URI 和 URL
每个 Web 服务器资源都有一个名字，这样客户端就可以说明他们感兴趣的资源是什么了，服务器资源名被称为统一资源标识符（Uniform Resource Identifier,URI）。URI 就像因特网上的邮政地址一样，在世界范围内唯一标识并定位信息资源。
统一资源定位符（URL）是资源标识符最常见的形式。URL 描述了一台特定服务器上某资源的特定位置。
现在几乎所有的 URI 都是 URL。
URI 的第二种形式就是统一资源名（URN）。URN 是作为特定内容的唯一名称使用的，与目前的资源所在地无关。
HTTP 消息的结构
事务和报文
客户端是怎样通过 HTTP 与 Web 服务器及其资源进行事务处理的呢？一个 HTTP 事务由一条请求命令（从客户端发往服务器）和一个响应（从服务器发回客户端）结果组成。这种通信是通过名为 HTTP 报文（HTTP Message）的格式化数据块进行的。
HTTP 事务：
报文：
HTTP 报文是纯文本，不是二进制代码。从 Web 客户端发往 Web 服务器的 HTTP 报文称为请求报文（request message）。从服务器发往客户端的报文称为响应报文。
HTTP 报文包括三部分：
起始行
首部字段
主体
方法
Http 协议定义了很多与服务器交互的方法，最基本的有 4 种，分别是 GET,POST,PUT,DELETE. 一个 URL 地址用于描述一个网络上的资源，而 HTTP 中的 GET, POST, PUT, DELETE 就对应着对这个资源的查，改，增，删 4 个操作。我们最常见的就是 GET 和 POST 了。GET 一般用于获取/查询资源信息，而 POST 一般用于更新资源信息。
GET
HEAD
PUT
POST
TRACE
OPTIONS
DELETE
Get 与 POST 的区别
GET 与 POST 是我们常用的两种 HTTP Method，二者之间的区别主要包括如下五个方面：
从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；
从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；
从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的 请求头 中，以?分割 URL 和传输数据，参数之间以 &相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX 中的 XX 为该符号以 16 进制表示的 ASCII)；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中。
就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全。
从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。
HTTP 请求结构：请求方式 + 请求 URI + 协议及其版本
HTTP 响应结构：状态码 + 原因短语 + 协议及其版本
状态码
每条 HTTP 响应报文返回时都会携带一个状态码。状态码是一个三位数字的代码，告知客户端请求是否成功，或者是都需要采取其他动作。
1xx：表明服务端接收了客户端请求，客户端继续发送请求；
2xx：客户端发送的请求被服务端成功接收并成功进行了处理；
3xx：服务端给客户端返回用于重定向的信息；
4xx：客户端的请求有非法内容；
5xx：服务端未能正常处理客户端的请求而出现意外错误。
200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）
206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的 GET 请求，响应报文中包含由 Content-Range 指定范围的实体内容。
301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的 URL，之后应使用更改的 URL；
302 Found：临时性重定向，表示请求的资源被分配了新的 URL，希望本次访问使用新的 URL；
303 See Other：表示请求的资源被分配了新的 URL，应使用 GET 方法定向获取请求的资源
304 Not Modified：表示客户端发送附带条件（是指采用 GET 方法的请求报文中包含 if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since 中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；
400 Bad Request:表示请求报文中存在语法错误；
401 Unauthorized：经许可，需要通过 HTTP 认证；
403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是 web 应用存在的 bug 或某些临时的错误时；
503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；
HTTP 是个应用层协议。HTTP 无需操心网络通信的具体细节，而是把这些细节都交给了通用可靠的因特网传输协议 TCP/IP。
在 HTTP 客户端向服务器发送报文之前，需要用网络协议（Internet Protocol，IP）地址和端口号在客户端和服务器之间建立一条 TCP/IP 协议。而 IP 地址就是通过 URL 提供的，像 http://207.200.21.11:80/index.html，还有使用域名服务（Domain Name Services，DNS）的 http://www.lazyegg.net。
协议版本
HTTP/0.9
HTTP/1.0
增加了请求方式 POST 和 HEAD
不再局限于 0.9 版本的 HTML 格式，根据 Content-Type 可以支持多种数据格式，即 MIME 多用途互联网邮件扩展，例如 text/html、image/jpeg 等
同时也开始支持 cache，就是当客户端在规定时间内访问统一网站，直接访问 cache 即可
HTTP 请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等
但是 1.0 版本的工作方式是每次 TCP 连接只能发送一个请求，当服务器响应后就会关闭这次连接，下一个请求需要再次建立 TCP 连接，就是不支持 keepalive
HTTP/1.0+
HTTP/1.1
http1.1 是目前最为主流的 http 协议版本，从 1997 年发布至今，仍是主流的 http 协议版本。
引入了持久连接，或叫长连接（ persistent connection），即 TCP 连接默认不关闭，可以被多个请求复用，不用声明 Connection: keep-alive。
引入了管道机制（ pipelining），即在同一个 TCP 连接里，客户端可以同时发送多个请求，进一步改进了 HTTP 协议的效率。
新增方法：PUT、 PATCH、 OPTIONS、 DELETE。
http 协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度。
HTTP/2.0（又名 HTTP-NG）
http/2 发布于 2015 年，目前应用还比较少。
http/2 是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
复用 TCP 连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了队头堵塞的问题,此双向的实时通信称为多工（ Multiplexing）。
HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送。
引入头信息压缩机制（ header compression） ,头信息使用 gzip 或 compress 压缩后再发送。
四、HTTPS
HTTP 缺点：
通信使用明文不对数据进行加密（内容容易被窃听）
不验证通信方身份（容易伪装）
无法确定报文完整性（内容易被篡改）
因此，HTTP 协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
为了解决 HTTP 协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议 HTTPS，为了数据传输的安全，HTTPS 在 HTTP 的基础上加入了 SSL（安全套接层）协议，SSL 依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
与 SSL（安全套接层）组合使用的 HTTP 就是 HTTPS
img
HTTP 和 HTTPS 对比
HTTP 协议传输的数据都是未加密的，也就是明文的，因此使用 HTTP 协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了 SSL（Secure Sockets Layer）协议用于对 HTTP 协议传输的数据进行加密，从而就诞生了 HTTPS。简单来说，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全。
HTTPS 和 HTTP 的区别主要如下：
https 协议需要到 ca 申请证书，一般免费证书较少，因而需要一定费用。
http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl 加密传输协议。
http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
http 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。
对称加密与非对称加密
主要的加密方法分为两种：一种是共享密钥加密（对称密钥加密），一种是公开密钥加密（非对称密钥加密）
共享密钥加密(对称秘钥加密)
加密与解密使用同一个密钥，常见的对称加密算法：DES，AES，3DES 等。
img
也就是说在加密的同时，也会把密钥发送给对方。在发送密钥过程中可能会造成密钥被窃取，那么如何解决这一问题呢？
公开密钥（非对称密钥）
公开密钥使用一对非对称密钥。一把叫私有密钥，另一把叫公开密钥。私有密钥不让任何人知道，公有密钥随意发送。公钥加密的信息，只有私钥才能解密。常见的非对称加密算法：RSA，ECC 等。
也就是说，发送密文方使用对方的公开密钥进行加密，对方接受到信息后，使用私有密钥进行解密。
对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
为了解决这一问题，https 采用对称加密与非对称加密的混合加密方式。
SSL/TSL
SSL（Secure Sockets Layer），中文叫做“安全套接层”。它是在上世纪 90 年代中期，由网景公司设计的。
SSL 协议就是用来解决 HTTP 传输过程的不安全问题，到了 1999 年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。
很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。
SSL/TLS 协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
公钥加密计算量太大，如何减少耗用的时间？
因此，SSL/TLS 协议的基本过程是这样的：
服务端将非对称加密的公钥发送给客户端；
客户端拿着服务端发来的公钥，对对称加密的 key 做加密并发给服务端；
服务端拿着自己的私钥对发来的密文解密，从来获取到对称加密的 key；
二者利用对称加密的 key 对需要传输的消息做加解密传输。
HTTPS 相比 HTTP，在请求前多了一个「握手」的环节。
握手过程中确定了数据加密的密码。在握手过程中，网站会向浏览器发送 SSL 证书，SSL 证书和我们日常用的身份证类似，是一个支持 HTTPS 网站的身份证明，SSL 证书里面包含了网站的域名，证书有效期，证书的颁发机构以及用于加密传输密码的公钥等信息，由于公钥加密的密码只能被在申请证书时生成的私钥解密，因此浏览器在生成密码之前需要先核对当前访问的域名与证书上绑定的域名是否一致，同时还要对证书的颁发机构进行验证，如果验证失败浏览器会给出证书错误的提示。
证书
实际上，我们使用的证书分很多种类型，SSL 证书只是其中的一种。证书的格式是由 X.509 标准定义。SSL 证书负责传输公钥，是一种 PKI（Public Key Infrastructure，公钥基础结构）证书。
我们常见的证书根据用途不同大致有以下几种：
SSL 证书，用于加密 HTTP 协议，也就是 HTTPS。
代码签名证书，用于签名二进制文件，比如 Windows 内核驱动，Firefox 插件，Java 代码签名等等。
客户端证书，用于加密邮件。
双因素证书，网银专业版使用的 USB Key 里面用的就是这种类型的证书。
这些证书都是由受认证的证书颁发机构——我们称之为 CA（Certificate Authority）机构来颁发，针对企业与个人的不同，可申请的证书的类型也不同，价格也不同。CA 机构颁发的证书都是受信任的证书，对于 SSL 证书来说，如果访问的网站与证书绑定的网站一致就可以通过浏览器的验证而不会提示错误。
为什么服务端要发送证书给客户端
互联网有太多的服务需要使用证书来验证身份，以至于客户端(操作系统或浏览器等)无法内置所有证书，需要通过服务端将证书发送给客户端。
客户端为什么要验证接收到的证书
中间人攻击
客户端如何验证接收到的证书
为了回答这个问题，需要引入数字签名(Digital Signature)。
将一段文本通过哈希（hash）和私钥加密处理后生成数字签名。
假设消息传递在 Bob，Susan 和 Pat 三人之间发生。Susan 将消息连同数字签名一起发送给 Bob，Bob 接收到消息后，可以这样验证接收到的消息就是 Susan 发送的
当然，这个前提是 Bob 知道 Susan 的公钥。更重要的是，和消息本身一样，公钥不能在不安全的网络中直接发送给 Bob。此时就引入了证书颁发机构（Certificate Authority，简称 CA），CA 数量并不多，Bob 客户端内置了所有受信任 CA 的证书。CA 对 Susan 的公钥（和其他信息）数字签名后生成证书。
Susan 将证书发送给 Bob 后，Bob 通过 CA 证书的公钥验证证书签名。
Bob 信任 CA，CA 信任 Susan 使得 Bob 信任 Susan，信任链（Chain Of Trust）就是这样形成的。
事实上，Bob 客户端内置的是 CA 的根证书(Root Certificate)，HTTPS 协议中服务器会发送证书链（Certificate Chain）给客户端。
HTTPS 的工作原理
Client 使用 https 的 URL 访问 Server，要求与 Server 建立 SSL 连接
Server 把事先配置好的公钥证书返回给客户端。
Client 验证公钥证书：比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在 CRL 吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的 Root 证书或者 Client 内置的 Root 证书）。如果验证通过则继续，不通过则显示警告信息。
Client 使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给 Server。
Server 使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client 和 Server 双方都持有了相同的对称密钥。
Server 使用对称密钥加密“明文内容 A”，发送给 Client。
Client 使用对称密钥解密响应的密文，得到“明文内容 A”。
Client 再次发起 HTTPS 的请求，使用对称密钥加密请求的“明文内容 B”，然后 Server 使用对称密钥解密密文，得到“明文内容 B”。
HTTPS 的优点
尽管 HTTPS 并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但 HTTPS 仍是现行架构下最安全的解决方案，主要有以下几个好处：
使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起同等 HTTP 网站，采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。
HTTPS 的缺点
虽然说 HTTPS 有很大的优势，但其相对来说，还是存在不足之处的：
HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10%到 20%的耗电；
HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗。
HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。
HTTP 切换到 HTTPS
如果需要将网站从 http 切换到 https 到底该如何实现呢？
这里需要将页面中所有的链接，例如 js，css，图片等等链接都由 http 改为 https。例如：http://www.baidu.com改为https://www.baidu.com
BTW，这里虽然将 http 切换为了 https，还是建议保留 http。所以我们在切换的时候可以做 http 和 https 的兼容，具体实现方式是，去掉页面链接中的 http 头部，这样可以自动匹配 http 头和 https 头。例如：将http://www.baidu.com改为//www.baidu.com。然后当用户从 http 的入口进入访问页面时，页面就是 http，如果用户是从 https 的入口进入访问页面，页面即使 https 的。
什么是 Cookie，Cookie 的使用过程是怎么样的？
由于 http 协议是无状态协议，如果客户通过浏览器访问 web 应用时没有一个保存用户访问状态的机制，那么将不能持续跟踪应用的操作。比如当用户往购物车中添加了商品，web 应用必须在用户浏览别的商品的时候仍保存购物车的状态，以便用户继续往购物车中添加商品。
cookie 是浏览器的一种缓存机制，它可用于维持客户端与服务器端之间的会话。由于下面一题会讲到 session，所以这里要强调 cookie 会将会话保存在客户端（session 则是把会话保存在服务端）
这里以最常见的登陆案例讲解 cookie 的使用过程：
首先用户在客户端浏览器向服务器发起登陆请求
登陆成功后，服务端会把登陆的用户信息设置 cookie 中，返回给客户端浏览器
客户端浏览器接收到 cookie 请求后，会把 cookie 保存到本地（可能是内存，也可能是磁盘，看具体使用情况而定）
以后再次访问该 web 应用时，客户端浏览器就会把本地的 cookie 带上，这样服务端就能根据 cookie 获得用户信息了
什么是 session，有哪些实现 session 的机制？
session 是一种维持客户端与服务器端会话的机制。但是与 cookie 把会话信息保存在客户端本地不一样，session 把会话保留在浏览器端。
我们同样以登陆案例为例子讲解 session 的使用过程：
首先用户在客户端浏览器发起登陆请求
登陆成功后，服务端会把用户信息保存在服务端，并返回一个唯一的 session 标识给客户端浏览器。
客户端浏览器会把这个唯一的 session 标识保存在起来
以后再次访问 web 应用时，客户端浏览器会把这个唯一的 session 标识带上，这样服务端就能根据这个唯一标识找到用户信息。
看到这里可能会引起疑问：把唯一的 session 标识返回给客户端浏览器，然后保存起来，以后访问时带上，这难道不是 cookie 吗？
没错，session 只是一种会话机制，在许多 web 应用中，session 机制就是通过 cookie 来实现的。也就是说它只是使用了 cookie 的功能，并不是使用 cookie 完成会话保存。与 cookie 在保存客户端保存会话的机制相反，session 通过 cookie 的功能把会话信息保存到了服务端。
进一步地说，session 是一种维持服务端与客户端之间会话的机制，它可以有不同的实现。以现在比较流行的小程序为例，阐述一个 session 的实现方案：
首先用户登陆后，需要把用户登陆信息保存在服务端，这里我们可以采用 redis。比如说给用户生成一个 userToken，然后以 userId 作为键，以 userToken 作为值保存到 redis 中，并在返回时把 userToken 带回给小程序端。
小程序端接收到 userToken 后把它缓存起来，以后每当访问后端服务时就把 userToken 带上。
在后续的服务中服务端只要拿着小程序端带来的 userToken 和 redis 中的 userToken 进行比对，就能确定用户的登陆状态了。
session 和 cookie 有什么区别
经过上面两道题的阐述，这道题就很清晰了
cookie 是浏览器提供的一种缓存机制，它可以用于维持客户端与服务端之间的会话
session 指的是维持客户端与服务端会话的一种机制，它可以通过 cookie 实现，也可以通过别的手段实现。
如果用 cookie 实现会话，那么会话会保存在客户端浏览器中
而 session 机制提供的会话是保存在服务端的。
Other FAQ
从输入网址到获得页面的过程
浏览器查询 DNS，获取域名对应的 IP 地址:具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。对于向本地 DNS 服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；
TCP/IP 链接建立起来后，浏览器向服务器发送 HTTP 请求；
服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
XSS 攻击
XSS 是一种经常出现在 web 应用中的计算机安全漏洞，与 SQL 注入一起成为 web 中最主流的攻击方式。XSS 是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到 web 页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
IP 地址的分类
IP 地址是指互联网协议地址，是 IP 协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP 地址编址方案将 IP 地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。
每个 IP 地址包括两个标识码（ID），即网络 ID 和主机 ID。同一个物理网络上的所有主机都使用同一个网络 ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：
A 类地址：以 0 开头，第一个字节范围：0~127；
B 类地址：以 10 开头，第一个字节范围：128~191；
C 类地址：以 110 开头，第一个字节范围：192~223；
D 类地址：以 1110 开头，第一个字节范围为 224~239；
E 类地址：以 1111 开头，保留地址
关注公众号：网络技术平台，回复 “ *资料* ” 获取视频、培训教程、实验手册、电子书。
评论