一些相当基础的知识-计算机网络部分

OSI的七层协议与TCP/IP的四层协议

学习计算机网络时我们一般采用折中的办法，也就是中和 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚。

1.1 应用层

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。 应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议等等。我们把应用层交互的数据单元称为报文。

表示层的三个功能：数据格式变换、数据加密解密、数据压缩恢复

域名系统

域名系统(Domain Name System缩写 DNS，Domain Name被译为域名)是因特网的一项核心服务，它作为可以将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。（百度百科）例如：一个公司的 Web 网站可看作是它在网上的门户，而域名就相当于其门牌地址，通常域名都使用该公司的名称或简称。

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。

端口号：所谓的端口，就好像是门牌号一样，[客户端]可以通过ip地址找到对应的[服务器端]，但是服务器端是有很多端口的，每个 [应用程序] 对应一个端口号，通过类似门牌号的端口号，客户端才能真正的访问到该服务器。为了对端口进行区分，将每个端口进行了编号，这就是端口号。

网络服务	端口号	套接字
FTP数据	20	tcp
FTP控制	21	tcp
SSH	22	tcp
Telnet	23	tcp
SMTP	25	tcp
HTTP	80	tcp
POP3	110	tcp
HTTPS	443	tcp
SOCKS	1080	tcp
DNS	53	udp
DHCP	67	udp
TFTP	69	udp
MySQL	3306
Mongodb	27017
Tomcat	8080

1.2 运输层

运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

功能：可靠传输/不可靠传输、差错控制、流量控制、复用分用

运输层主要使用以下两种协议:

0. 传输控制协议 TCP（Transmission Control Protocol）--提供面向连接的，可靠的数据传输服务。
1. 用户数据协议 UDP（User Datagram Protocol）--提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

1.3 网络层

在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。

这里要注意：不要把运输层的“用户数据报 UDP ”和网络层的“ IP 数据报”弄混。另外，无论是哪一层的数据单元，都可笼统地用“分组”来表示。

这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称.

互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Internet Protocol）和许多路由选择协议，因此互联网的网络层也叫做网际层或IP层。

功能：路由选择、流量控制、差错控制、拥塞控制

1.4 数据链路层

数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。 控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。

1.5 物理层

在物理层上所传送的数据单位是比特。

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异， 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

在互联网使用的各种协中最重要和最著名的就是 TCP/IP 两个协议。现在人们经常提到的TCP/IP并不一定单指TCP和IP这两个具体的协议，而往往表示互联网所使用的整个TCP/IP协议族。

1.6 总结一下

上面我们对计算机网络的五层体系结构有了初步的了解，下面附送一张七层体系结构图总结一下（图片来源于网络）。

TCP 三次握手和四次挥手

为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。

TCP 三次握手漫画图解

如下图所示，下面的两个机器人通过3次握手确定了对方能正确接收和发送消息。

简单示意图：

第一次握手（SYN=1, Seq=x）

客户端发送一个TCP的SYN标志位为1的包，指明客户端打算连接的服务器的端口，以及初始序号x，保存在包头的序列号Sequence Number字段里。

发送完毕后，客户端进入SYN_SEND状态。

第二次握手（SYN=1, ACK=1, Seq=y, ACKnum=x+1）

服务端发回确认包（ACK）应答，即SYN标志位和ACK标志位均为1。服务端选择自己的ISN序列号放到Seq域里，同时将确认序号Acknowledgement Number设置为为客户端ISN加1，即x+1。

发送完毕后，服务端进入SYN_RCVD状态。

第三次握手（ACK=1, ACKnum=y+1）

客户端再次发送确认包（ACK），SYN标志位为0，ACK标志位为1，并且把服务端发来的ACK序号字段加1，即y+1，放在确定字段中发送给对方。

发送完毕后，客户端进入ESTABLISHED状态，当服务端接到这个包时，也进入ESTABLISHED状态，至此TCP握手结束。

为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

第2次握手传回了ACK，为什么还要传回SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。”

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

为什么要四次挥手

断开一个 TCP 连接则需要“四次挥手”：

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个FIN给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

TCP,UDP 协议的区别

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

TCP 协议如何保证可靠传输

0. 应用数据被分割成 TCP 认为最适合发送的数据块。
1. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
2. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
3. TCP 的接收端会丢弃重复的数据。
4. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
5. 拥塞控制： 当网络拥塞时，减少数据的发送。
6. ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
7. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

优缺点：

• 优点： 简单
• 缺点： 信道利用率低，等待时间长

1) 无差错情况:

发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况（超时重传）:

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

3) 确认丢失和确认迟到

• 确认丢失 ：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
• 确认迟到 ：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。

连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优缺点：

• 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
• 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

滑动窗口和流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
• 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

在浏览器中输入url地址到显示主页的过程

上图有一个错误，请注意，是OSPF不是OPSF。 OSPF（Open Shortest Path First，ospf）开放最短路径优先协议,是由Internet工程任务组开发的路由选择协议

总体来说分为以下几个过程:

0. DNS解析
1. TCP连接
2. 发送HTTP请求
3. 服务器处理请求并返回HTTP报文
4. 浏览器解析渲染页面
5. 连接结束

HTTP 方法

客户端发送的 请求报文 第一行为请求行，包含了方法字段。

\1. GET：获取资源，当前网络中绝大部分使用的都是 GET；

\2. HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；

\3. POST：传输实体主体

\4. PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

\5. PATCH：对资源进行部分修改。PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

\6. OPTIONS：查询指定的 URL 支持的方法；

\7. CONNECT：要求在与代理服务器通信时建立隧道。使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

\8. TRACE：追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

GET 和 POST 的区别

GET 和 POST 本质都是 HTTP 请求，只不过对它们的作用做了界定和适配，并且让他们适应各自的场景。

本质区别：GET 只是一次 HTTP请求，POST 先发请求头再发请求体，实际上是两次请求。

\1. 从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；

\2. 从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；

\3. 从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的 请求头 中，以 ? 分割 URL 和传输数据，参数之间以 & 相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中 ％XX 中的 XX 为该符号以 16 进制表示的 ASCII)；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中；

\4. 就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全；

\5. 从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。

状态码

200	请求已成功，请求所希望的响应头或数据体将随此响应返回。
404	请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
302	请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。　　新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。　　如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。　　注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。
500	服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。

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

各种协议与HTTP协议之间的关系

HTTP长连接,短连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

HTTP是不保存状态的协议,如何保存用户状态

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

HTTP 版本（1.0、1.1、2.0）

http1.0与1.1

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

0. 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。

1. 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

2. 缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

3. 带宽优化及网络连接的使用 :HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

   http2.0相对1.x的优点

   HTTP2 提高了网页的性能。 在 HTTP1 中浏览器限制了同一个域名下的请求数量（Chrome 下一般是六个），当在请求很多资源的时候，超过限制数目的请求会被阻塞。 HTTP2 中引入了多路复用的技术，这个技术可以只通过一个 TCP 连接就可以传输所有的请求数据。多路复用可以绕过浏览器限制同一个域名下的请求数量的问题，进而提高了网页的性能。

十二 URI和URL的区别是什么?

他们都是指定一个资源的方法，URL是URI的子集，是URI的一种。

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI的作用像身份证号一样，URL的作用更像地理位置一样，他们都可以定位到唯一的资源。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

十三 HTTP 和 HTTPS 的区别？

0. 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

1. 安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

   • 对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
   • 非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

2. HTTPS在传输的过程中会涉及到三个密钥：

   服务器端的公钥和私钥，用来进行非对称加密

   客户端生成的随机密钥，用来进行对称加密

3. HTTPS的工作过程

   \1. 客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了；

   \2. 服务器发出加密公钥 服务器从中选出一套加密算法和 hash 算法以及自己的身份信息（地址等）以证书的形式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构；同时服务器保存对应的私钥；

   \3. 客户端收到网站的证书之后要做下面的事情：

   3.1 验证证书的合法性；

   3.2 如果验证通过证书，浏览器会生成一串随机数，即客户端密钥的明文，并用证书中的公钥进行加密，发给服务器；

   \4. 服务器接收到客户端传送来的信息，要做下面的事情：

   4.1 用私钥解析出客户端密钥，使用客户端密钥加密消息；

   \5. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。

十四、缓存

什么是浏览器缓存

浏览器缓存(Brower Caching)是浏览器在本地磁盘对用户最近请求过的文档进行存储，当访问者再次访问同一页面时，浏览器就可以直接从本地磁盘加载文档。

浏览器是如何判断是否使用缓存的

浏览器缓存的优点

1.减少了冗余的数据传输，节省了网费

2.减少了服务器的负担，大大提升了网站的性能

3.加快了客户端加载网页的速度

浏览器缓存主要有两类：协商缓存和强缓存。

1.强缓存： 不会向服务器发送请求，直接从缓存中读取资源，在chrome控制台的network选项中可以看到该请求返回200的状态码;

2.协商缓存： 向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果命中，则返回304状态码并带上新的response header通知浏览器从缓存中读取资源；

两者的共同点是，都是从客户端缓存中读取资源；区别是强缓存不会发请求，协商缓存会发请求。

强制缓存

Expires：response header里的过期时间，浏览器再次加载资源时，如果在这个过期时间内，则命中强缓存。

Cache-Control：当值设为max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。

cache-control除了该字段外，还有下面几个比较常用的设置值：

-no-cache： 不使用本地缓存。需要使用缓存协商，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。

-no-store： 直接禁止浏览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。

-public： 可以被所有的用户缓存，包括终端用户和CDN等中间代理服务器。

-private： 只能被终端用户的浏览器缓存，不允许CDN等中继缓存服务器对其缓存。

协商缓存

比较客户端缓存的资源和服务端资源，有没有被修改过。比较方式有两种

比较修改时间的Last-Modify/If-Modify-Since：浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间；当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存

比较资源哈希的Etag/If-None-Match：web服务器响应请求时，告诉浏览器当前资源在服务器的唯一标识（生成规则由服务器决定，一般就是根据资源生成的哈希，资源被修改过哈希也会变）。如果资源具有Etag声明，则再次向web服务器请求时带上头If-None-Match: Etag的值。web服务器收到请求后发现有头If-None-Match 则与被请求资源的相应校验串进行比对，决定是否命中协商缓存；

ETag和Last-Modified的作用和用法，他们的区别：

1.Etag要优于Last-Modified。Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；

2.在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值；

3.在优先级上，服务器校验优先考虑Etag。

浏览器缓存过程

1.浏览器第一次加载资源，服务器返回200，浏览器将资源文件从服务器上请求下载下来，并把response header及该请求的返回时间一并缓存；

2.下一次加载资源时，先比较当前时间和上一次返回200时的时间差，如果没有超过cache-control设置的max-age，则没有过期，命中强缓存，不发请求直接从本地缓存读取该文件（如果浏览器不支持HTTP1.1，则用expires判断是否过期）；如果时间过期，则向服务器发送header带有If-None-Match和If-Modified-Since的请求

3.服务器收到请求后，优先根据Etag的值判断被请求的文件有没有做修改，Etag值一致则没有修改，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回200；；

4.如果服务器收到的请求没有Etag值，则将If-Modified-Since和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回200；

HTML4的本地存储 cookie

浏览器的缓存机制提供了可以将用户数据存储在客户端上的方式，可以利用cookie,session等跟服务端进行数据交互。

一、cookie和session

cookie和session都是用来跟踪浏览器用户身份的会话方式。

区别：

1、保持状态：cookie保存在浏览器端，session保存在服务器端

2、使用方式：

（1）cookie机制：如果不在浏览器中设置过期时间，cookie被保存在内存中，生命周期随浏览器的关闭而结束，这种cookie简称会话cookie。如果在浏览器中设置了cookie的过期时间，cookie被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，直到过期时间结束才消失。

Cookie是服务器发给客户端的特殊信息，cookie是以文本的方式保存在客户端，每次请求时都带上它

（2）session机制：当服务器收到请求需要创建session对象时，首先会检查客户端请求中是否包含sessionid。如果有sessionid，服务器将根据该id返回对应session对象。如果客户端请求中没有sessionid，服务器会创建新的session对象，并把sessionid在本次响应中返回给客户端。通常使用cookie方式存储sessionid到客户端，在交互中浏览器按照规则将sessionid发送给服务器。如果用户禁用cookie，则要使用URL重写，可以通过response.encodeURL(url) 进行实现；API对encodeURL的结束为，当浏览器支持Cookie时，url不做任何处理；当浏览器不支持Cookie的时候，将会重写URL将SessionID拼接到访问地址后。

3、存储内容：cookie只能保存字符串类型，以文本的方式；session通过类似与Hashtable的数据结构来保存，能支持任何类型的对象(session中可含有多个对象)

4、存储的大小：cookie：单个cookie保存的数据不能超过4kb；session大小没有限制。

5、安全性：cookie：针对cookie所存在的攻击：Cookie欺骗，Cookie截获；session的安全性大于cookie。

　　　　　　原因如下：（1）sessionID存储在cookie中，若要攻破session首先要攻破cookie；

　　　　　　　　　　　（2）sessionID是要有人登录，或者启动session_start才会有，所以攻破cookie也不一定能得到sessionID；

　　　　　　　　　　　（3）第二次启动session_start后，前一次的sessionID就是失效了，session过期后，sessionID也随之失效。

　　　　　　　　　　　（4）sessionID是加密的

　　　　　　　　　　　（5）综上所述，攻击者必须在短时间内攻破加密的sessionID，这很难。

6、应用场景：

cookie：（1）判断用户是否登陆过网站，以便下次登录时能够实现自动登录（或者记住密码）。如果我们删除cookie，则每次登录必须从新填写登录的相关信息。

　　　　（2）保存上次登录的时间等信息。

　　　　（3）保存上次查看的页面

　　　　（4）浏览计数

session：Session用于保存每个用户的专用信息，变量的值保存在服务器端，通过SessionID来区分不同的客户。

　　（1）网上商城中的购物车

　　（2）保存用户登录信息

　　（3）将某些数据放入session中，供同一用户的不同页面使用

　　（4）防止用户非法登录

7、缺点：cookie：（1）大小受限

　　　　　　　　（2）用户可以操作（禁用）cookie，使功能受限

　　　　　　　　（3）安全性较低

　　　　　　　　（4）有些状态不可能保存在客户端。

　　　　　　　　（5）每次访问都要传送cookie给服务器，浪费带宽。

　　　　　　　　（6）cookie数据有路径（path）的概念，可以限制cookie只属于某个路径下。

　　　session：（1）Session保存的东西越多，就越占用服务器内存，对于用户在线人数较多的网站，服务器的内存压力会比较大。

　　　　　　　　（2）依赖于cookie（sessionID保存在cookie），如果禁用cookie，则要使用URL重写，不安全

　　　　　　　　（3）创建Session变量有很大的随意性，可随时调用，不需要开发者做精确地处理，所以，过度使用session变量将会导致代码不可读而且不好维护。

HTML5的本地存储

解释一

HTML5中与本地存储相关的两个重要内容：Web Storage与本地数据库。其中，Web Storage存储机制是对HTML4中cookie存储机制的一个改善。由于cookie存储机制有很多缺点，HTML5不再使用它，转而使用改良后的Web Storage存储机制。本地数据库是HTML5中新增的一个功能，使用它可以在客户端本地建立一个数据库，原本必须保存在服务器端数据库中的内容现在可以直接保存在客户端本地了，这大大减轻了服务器端的负担，同时也加快了访问数据的速度。

本文主要来讲解Web Storage

我们知道，在HTML4中可以使用cookie在客户端保存诸如用户名等简单的用户信息，但是，通过长期的使用，你会发现，用cookie存储永久数据存在以下几个问题：

1.大小：cookie的大小被限制在4KB。

2.带宽：cookie是随HTTP事务一起被发送的，因此会浪费一部分发送cookie时使用的带宽。

3.复杂性：要正确的操纵cookie是很困难的。

针对这些问题，在HTML5中，重新提供了一种在客户端本地保存数据的功能，它就是Web Storage。

具体来说，Web Storage又分为两种：

1.sessionStorage：将数据保存在session对象中。所谓session，是指用户在浏览某个网站时，从进入网站到浏览器关闭所经过的这段时间，也就是用户浏览这个网站所花费的时间。session对象可以用来保存在这段时间内所要求保存的任何数据。

2.localStorage：将数据保存在客户端本地的硬件设备(通常指硬盘，也可以是其他硬件设备)中，即使浏览器被关闭了，该数据仍然存在，下次打开浏览器访问网站时仍然可以继续使用。

这两者的区别在于，sessionStorage为临时保存，而localStorage为永久保存。

到目前为止，Firefox3.6以上、Chrome6以上、Safari 5以上、Pera10.50以上、IE8以上版本的浏览器支持sessionStorage与localStorage的使用。

解释二

WebStorage的目的是克服由cookie所带来的一些限制，当数据需要被严格控制在客户端时，不需要持续的将数据发回服务器。

WebStorage两个主要目标：（1）提供一种在cookie之外存储会话数据的路径。（2）提供一种存储大量可以跨会话存在的数据的机制。

HTML5的WebStorage提供了两种API：localStorage（本地存储）和sessionStorage（会话存储）。

1、生命周期：localStorage:localStorage的生命周期是永久的，关闭页面或浏览器之后localStorage中的数据也不会消失。localStorage除非主动删除数据，否则数据永远不会消失。

　　　　　　 sessionStorage的生命周期是在仅在当前会话下有效。sessionStorage引入了一个“浏览器窗口”的概念，sessionStorage是在同源的窗口中始终存在的数据。只要这个浏览器窗口没有关闭，即使刷新页面或者进入同源另一个页面，数据依然存在。但是sessionStorage在关闭了浏览器窗口后就会被销毁。同时独立的打开同一个窗口同一个页面，sessionStorage也是不一样的。

2、存储大小：localStorage和sessionStorage的存储数据大小一般都是：5MB

3、存储位置：localStorage和sessionStorage都保存在客户端，不与服务器进行交互通信。

4、存储内容类型：localStorage和sessionStorage只能存储字符串类型，对于复杂的对象可以使用ECMAScript提供的JSON对象的stringify和parse来处理

5、获取方式：localStorage：window.localStorage;；sessionStorage：window.sessionStorage;。

6、应用场景：localStoragese：常用于长期登录（+判断用户是否已登录），适合长期保存在本地的数据。sessionStorage：敏感账号一次性登录；

WebStorage的优点：

（1）存储空间更大：cookie为4KB，而WebStorage是5MB；

（2）节省网络流量：WebStorage不会传送到服务器，存储在本地的数据可以直接获取，也不会像cookie一样美词请求都会传送到服务器，所以减少了客户端和服务器端的交互，节省了网络流量；

（3）对于那种只需要在用户浏览一组页面期间保存而关闭浏览器后就可以丢弃的数据，sessionStorage会非常方便；

（4）快速显示：有的数据存储在WebStorage上，再加上浏览器本身的缓存。获取数据时可以从本地获取会比从服务器端获取快得多，所以速度更快；

（5）安全性：WebStorage不会随着HTTP header发送到服务器端，所以安全性相对于cookie来说比较高一些，不会担心截获，但是仍然存在伪造问题；

（6）WebStorage提供了一些方法，数据操作比cookie方便；

　　　　setItem (key, value) —— 保存数据，以键值对的方式储存信息。

　　 getItem (key) —— 获取数据，将键值传入，即可获取到对应的value值。

　　removeItem (key) —— 删除单个数据，根据键值移除对应的信息。

　　clear () —— 删除所有的数据

　　key (index) —— 获取某个索引的key

cookie 、sessionStorage与localStorage的区别

Web存储

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。

Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

web存储概念简介

web存储指的是在web通信过程中，由客户端（如浏览器）对少量数据进行的本地存储（注：本文所说的是广义的web存储，而不单指Web Storage）。web存储类型主要包括古老的cookie，以及HTML5推出的sessionStorage、localStorage和indexedDB等。

web存储的宿主环境通常是浏览器，借助浏览器提供的JavaScript接口，我们可以实现对这些数据的增删改查。

为什么需要web存储？ 这要从最古老的的cookie说起。

cookie的诞生源于这样一个矛盾：http协议是无状态的，而服务端却有区分不同客户端的实际需要。

先来理解http协议的无状态性。无状态性指的是，http协议对任意两次数据传输是没有记忆能力的。举个例子，假如某个客户端先向服务端发送了一条消息，随后又向服务端发送了另一条消息，那么服务器无法知道这两条消息来自同一个客户端。

之所以要将http协议设计为无状态的，是因为要维护所有客户端的连接状态对服务端的性能消耗很大，这会严重限制服务器的并发能力。并且在大多数情况下，维护这个状态并不能带来什么收益。所以http协议的设计者索性不对状态进行维护。

但在很多情况下，服务端必须区分不同的客户端。拿淘宝来说，在收到下单请求时，服务器必须知道是哪个用户在下单，这就要求它必须知道当前的下单请求和之前的哪个登录请求来自同一个客户端（否则该客户端每次发请求都必须把自己的账号信息和所有参数带上）。

为此，服务端设计了session（会话）机制。一个用户登录之后，服务端会为该用户创建一个会话对象，存储与该用户相关的参数（如用户名、登录时间等），这个对象直到用户退出登录或登录超时才会被销毁。每个会话对象有一个唯一的id，客户端只要在随后发送的请求中携带上这个id，服务端就能确定是哪个用户发送的请求。

这样，客户端必须有一种存储这个id的机制，来保证其在退出登录前的每个请求中都可以携带这个id。于是，cookie诞生了。

用户登录时，服务端会为该用户创建一个会话（session）对象，然后服务端把会话对象的id写入响应参数中发送给客户端。客户端收到响应后，取出该参数，保存在浏览器内。随后每次发送请求时都携带上这个id，服务端根据这个id，就可以确定该请求来自于哪个用户。这个用于存储id的特殊字段，就称为cookie（当然，cookie不仅仅可以存储session的id，还可以存储其他参数）。

所以说，cookie的基本作用就是携带用户标识，帮助服务端区分不同的客户端。

cookie之后的几类存储：sessionStorage、localStorage和indexedDB出现的原因就很简单了：将更多的会话数据保存在浏览器端，可以减少网络传输，提升网站性能（虽然cookie也可以这样使用，但它的单个容量只有4KB，所以不适合这类用途）。

web存储详解

cookie

上面我们已经对cookie的来源进行了详细的介绍，这里要介绍的是cookie的用法及特点。

HTTP Cookie简称cookie，是在服务端HTTP请求发送Set-Cookie HTTP头作为响应的一部分，通过name=value的形式存储的字符串。前端收到该响应后，会将cookie保存在浏览器内，并在每次的用户请求中携带该字符串。

cookie在前端可以通过document.cookie获得，如：

document.cookie
< "_ga=77911531582348967; _gid=10966846041582958782"

上面的cookie里共存储了两个参数：ga和gid，两个参数由一个分号和一个空格隔开。cookie本身是用encodeURIComponent编码的，因此，如果cookie中包含中文，需要用对应的decodeURIComponent解码才能得到对应值。

除了key和value外，每个参数还会携带其他几个属性，包括域、路径、失效时间、安全标志等，这些参数在使用document.cookie输出时无法看到，不过可以在调试工具中查看：

上面几个参数的含义分别是：

key，键名。 value，键值。 Domain，cookie的域，即该网站所在的域，需要注意的是，cookie的域是不区分端口号的。 Path，cookie的存储路径，默认是当前项目的根路径。 Expires/Max-Age，cookie的失效时间，以毫秒为单位。不设置时默认在session失效时失效。 Size，cookie的大小。 HttpOnly，是否只能通过http请求传输。某些重要的cookie（如sessionId），只能由后台来设置，并且是不能随意修改的，就可以设置该标志位。 Secure，安全标志。设置了该参数后，该cookie只在https请求中才会被携带。 SameSite，为防止CSRF攻击和用户追踪而新增的安全属性，具体可参考阮一峰：Cookie 的 SameSite 属性。 一般来说，cookie只用于保存与登录相关的信息，其中最重要的是服务端会话（session）对象的id。它不适合存储大量的数据，因为浏览器限制了每个cookie的大小不能超过4KB。此外，浏览器对单个域下cookie的数量也是有限制的，该数量因浏览器而异，对开发者来说，这个数量一般不要超过20个。

cookie默认会在会话结束时失效，也可以手动修改max-age或Expires参数来设置cookie的失效时间，前者是规定cookie在多少秒后失效，而后者则是规定cookie在某个时间点失效。如果同时设置了这两个参数，则max-age优先级更高。

向cookie添加参数很简单：

document.cookie = "name=oeschger";
document.cookie = "favorite=tripe;max-age=120;path=/";
alert(document.cookie);
// 显示: name=oeschger; favorite=tripe

注意，我们为favorite设置的其他参数虽然没有通过document.cookie打印出来，但它们仍然是有效的。比如上面的name会在服务端的session销毁时失效，而favorite则会在120秒后失效。

cookie没有提供直接删除参数的接口，但是可以通过将参数的max-age属性设置为0或者将Expires设置为当前时间，来使其立即失效，以达到删除cookie的目的，如：

document.cookie = "favorite=; max-age=0;";

这样就可以从cookie中删除favorite。

这样就可以从cookie中删除favorite。

cookie作为客户端存储，有一个很大的优点，就是不受服务端架构的影响。我们知道，在分布式架构下，session很难在各个服务器之间共享。而cookie则完全不存在这个问题，它存储于客户端，可以被发送到任意一台服务器。

同时，cookie也存在几个很明显的缺点。一个是安全问题，cookie中存储了客户端的身份认证信息，如果被窃取，就可能产生不可预估的损失。另一个是上面提到的容量问题，这使得cookie不能广泛用于web存储。此外，cookie对通信带来的性能损耗也是不可忽视的。因为cookie中的所有参数会在每次向后端发送请求时被携带，如果cookie很大，就会导致每次的http请求体积变大，影响网站的响应速度。综上所述，cookie仅用于保存极少量的用户身份认证信息，并且需要通过加密策略保证cookie传输安全。

sessionStorage和localStorage

为什么要把这两个放在一起介绍呢？

因为它们都是继承自Storage，原理和语法上都有极高的相似性，以至于网上有大量关于两者异同的介绍文章。先来看看它们的相同点：

相同点

1.从原理上来说，两者都属于浏览器端存储。前者称为“会话存储”，后者称为“本地存储” 。它们都被部署在window对象上，因此可以通过下面的方式访问：

window.localStorage
// 或者直接访问localStorage
​
window.sessionStorage
// 或者直接访问sessionStorage

2.两者的操作语法是一致的（这里以localStorage为例）：

localStorage.setItem("name", "carter");  // 设置name: carter
​
localStorage.age = "24";   // 设置age: 24
​
localStorage.getItem("name");  // 获取name的值carter
​
localStorage.removeItem("name"); // 删除name
​
localStorage.clear();  // 清空localStorage

sessionStorage的语法同上。

3.两者都遵循同源策略。即该存储只在同一个域下可以共享，跨域无法访问，这样可以保证数据的安全性。

4.localStorage和sessionStorage各自拥有5MB的存储空间，并且只能保存字符串类型的数据。对于非字符串类型的数据，一般需要使用JSON.stringify方法压缩成字符串，使用时再用JSON.parse进行解析。

不同点

1.两者的失效时间是不同的。 localStorage本身是不会失效的，即使关闭浏览器，下次再访问该网站仍然有效。localStorage没有提供直接设置失效时间的方法，我们需要使用一种特殊的策略来定期清除localStorage：

localStorage.setItem("name", JSON.stringify({
  value: "carter",
  time: (new Date()).getTime() // 保存时间戳
}))
​
function getItem(key, maxAge){
  let obj = localStorage.getItem(key);
  if(obj){  // 获取变量值对象
    obj = JSON.parse(obj);
  }
  // 存储时间小于最大生命周期时才读取该参数，否则将其清除
  if((new Date()).getTime() - obj.time < maxAge){
    return obj.value;
  } else {
    localStorage.removeItem(key);
    return "";
  }
}
​
getItem("name", 60 * 60 * 1000);  // 失效时间为1小时

简单来说，就是把保存localStorage的时间一同存储进去，取值的时候再手动判断是否超时。

但sessionStorage与页面会话是绑定的，当某个页面会话失效时，对应的sessionStorage就会被清除。需要注意的是，sessionStorage只在会话页面失效时才会失效，也就是说刷新页面或者通过某种方式恢复当前页面时（如点击浏览器的回退按钮，或使用浏览器的页面恢复功能），sessionStorage并不会失效，换句话说，当某个页面创建了sessionStorage之后，它就总是与其创建的sessionStorage共存亡。

2.两者的有效范围不同。 在不跨域的情况下，localStorage可以跨页签生效，而sessionStorage仅在当前页签范围内有效。

这就是说，如果你新打开了一个与当前页面同域的页面，这个新页面会与当前页面共享localStorage，却不能共享sessionStorage。而如果你是在当前页面的iframe内打开的，并且没有跨域，那么localStorage和sessionStorage都是可以共享的。

indexedDB

尽管5M的空间已经相对较大了，但仍然无法满足所有的前端存储需求。

这是因为前端数据缓存对web站点的性能提升是巨大的（它可以有效减少http数据传输量，而这通常是导致网站卡顿的最主要因素），因此越来越多的站点倾向于在前端存储更多的数据。localStorage和sessionStorage无法满足这样的需求，因为一方面，它们的容量只有5M大小；另一方面，由于是非结构化存储，当数据量较大时，它们的操作速度不够快。

为此，HTML5规范推出了前端的事务型数据库indexedDB。它可以存储大量的结构化数据，具有几乎可以媲美后端数据库的读写性能（当然，从功能和容量上远不及后端数据库）。

使用indexedDB大概需要以下几个流程：

打开数据库

var request = window.indexedDB.open(databaseName, version);

这样就可以打开或新建一个indexedDB数据库。当所传入的数据库名不存在时，就会新建一个数据库，否则将打开已有数据库。当省略了数据库版本号时，如果数据库已存在，则默认为当前版本，否则版本号为1。

注册处理事件 调用open方法后，返回的是一个IDBRequest对象，通过向其注册error、success和upgradenedded事件，可以处理打开数据的结果。

error表示数据库打开失败：

request.onerror = function(err){
  console.log("数据库打开失败：" + err);
}

success表示数据库打开成功，此时可以执行数据库读操作：

success表示数据库打开成功，此时可以执行数据库读操作：

request.onsuccess = function (event) {
  let db = request.result;
  console.log('数据库打开成功');
};

upgradeneeded表示数据库需要升级，不同于一般的后端数据库，indexedDB每次修改数据库的内容都必须升级数据库版本：

request.onupgradeneeded = function (event) {
  let db = event.target.result;
}

需要注意的是，新建数据库的相关操作本身被归类为升级数据库版本，因此需要在upgradeneeded事件中进行：

request.onupgradeneeded = function (event) {
  db = event.target.result;
  var objectStore;
  if (!db.objectStoreNames.contains('person')) {
    objectStore = db.createObjectStore('person', { keyPath: 'id' });
  }
}

执行数据的增删改查操作 由于工作中暂未用到过indexedDB，缺少实际使用经验，因此这里暂不详述。如果感兴趣，请参考阮一峰：浏览器数据库 IndexedDB 入门教程。

前端存储与后端存储

我们上面所介绍的四类存储都属于前端存储，除了cookie之外，其他三个都是直接通过JavaScript来访问和操作的。

严格来说，除了cookie外，其他三类存储都不是绝对必要的，那我们为什么还需要前端存储呢？

答案是，减少http数据传输，提升网站性能。

WebSocket

一、为什么需要 WebSocket？

初次接触 WebSocket 的人，都会问同样的问题：我们已经有了 HTTP 协议，为什么还需要另一个协议？它能带来什么好处？

答案很简单，因为 HTTP 协议有一个缺陷：通信只能由客户端发起。

举例来说，我们想了解今天的天气，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。

这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。我们只能使用"轮询"：每隔一段时候，就发出一个询问，了解服务器有没有新的信息。最典型的场景就是聊天室。

轮询的效率低，非常浪费资源（因为必须不停连接，或者 HTTP 连接始终打开）。因此，工程师们一直在思考，有没有更好的方法。WebSocket 就是这样发明的。

二、简介

WebSocket 协议在2008年诞生，2011年成为国际标准。所有浏览器都已经支持了。

它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。

其他特点包括：

（1）建立在 TCP 协议之上，服务器端的实现比较容易。

（2）与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

（3）数据格式比较轻量，性能开销小，通信高效。

（4）可以发送文本，也可以发送二进制数据。

（5）没有同源限制，客户端可以与任意服务器通信。

（6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

ws://example.com:80/some/path

三、客户端的简单示例

WebSocket 的用法相当简单。

下面是一个网页脚本的例子（点击这里看运行结果），基本上一眼就能明白。

var ws = new WebSocket("wss://echo.websocket.org");
​
ws.onopen = function(evt) { 
console.log("Connection open ..."); 
ws.send("Hello WebSockets!");
};
​
ws.onmessage = function(evt) {
console.log( "Received Message: " + evt.data);
ws.close();
};
​
ws.onclose = function(evt) {
console.log("Connection closed.");
};      

四、客户端的 API

WebSocket 客户端的 API 如下。

4.1 WebSocket 构造函数

WebSocket 对象作为一个构造函数，用于新建 WebSocket 实例。

var ws = new WebSocket('ws://localhost:8080');

执行上面语句之后，客户端就会与服务器进行连接。

实例对象的所有属性和方法清单，参见这里。

4.2 webSocket.readyState

readyState属性返回实例对象的当前状态，共有四种。

• CONNECTING：值为0，表示正在连接。
• OPEN：值为1，表示连接成功，可以通信了。
• CLOSING：值为2，表示连接正在关闭。
• CLOSED：值为3，表示连接已经关闭，或者打开连接失败。

下面是一个示例。

switch (ws.readyState) {
case WebSocket.CONNECTING:
 // do something
 break;
case WebSocket.OPEN:
 // do something
 break;
case WebSocket.CLOSING:
 // do something
 break;
case WebSocket.CLOSED:
 // do something
 break;
default:
 // this never happens
 break;
}

4.3 webSocket.onopen

实例对象的onopen属性，用于指定连接成功后的回调函数。

ws.onopen = function () {
ws.send('Hello Server!');
}

如果要指定多个回调函数，可以使用addEventListener方法。

ws.addEventListener('open', function (event) {
ws.send('Hello Server!');
});

4.4 webSocket.onclose

实例对象的onclose属性，用于指定连接关闭后的回调函数。

ws.onclose = function(event) {
var code = event.code;
var reason = event.reason;
var wasClean = event.wasClean;
// handle close event
};
​
ws.addEventListener("close", function(event) {
var code = event.code;
var reason = event.reason;
var wasClean = event.wasClean;
// handle close event
});

4.5 webSocket.onmessage

实例对象的onmessage属性，用于指定收到服务器数据后的回调函数。

ws.onmessage = function(event) {
var data = event.data;
// 处理数据
};
​
ws.addEventListener("message", function(event) {
var data = event.data;
// 处理数据
});

注意，服务器数据可能是文本，也可能是二进制数据（blob对象或Arraybuffer对象）。

ws.onmessage = function(event){
if(typeof event.data === String) {
 console.log("Received data string");
}
​
if(event.data instanceof ArrayBuffer){
 var buffer = event.data;
 console.log("Received arraybuffer");
}
}

除了动态判断收到的数据类型，也可以使用binaryType属性，显式指定收到的二进制数据类型。

// 收到的是 blob 数据
ws.binaryType = "blob";
ws.onmessage = function(e) {
console.log(e.data.size);
};
​
// 收到的是 ArrayBuffer 数据
ws.binaryType = "arraybuffer";
ws.onmessage = function(e) {
console.log(e.data.byteLength);
};

4.6 webSocket.send()

实例对象的send()方法用于向服务器发送数据。

发送文本的例子。

ws.send('your message');

发送 Blob 对象的例子。

var file = document
.querySelector('input[type="file"]')
.files[0];
ws.send(file);

发送 ArrayBuffer 对象的例子。

// Sending canvas ImageData as ArrayBuffer
var img = canvas_context.getImageData(0, 0, 400, 320);
var binary = new Uint8Array(img.data.length);
for (var i = 0; i < img.data.length; i++) {
binary[i] = img.data[i];
}
ws.send(binary.buffer);

4.7 webSocket.bufferedAmount

实例对象的bufferedAmount属性，表示还有多少字节的二进制数据没有发送出去。它可以用来判断发送是否结束。

var data = new ArrayBuffer(10000000);
socket.send(data);
​
if (socket.bufferedAmount === 0) {
// 发送完毕
} else {
// 发送还没结束
}

4.8 webSocket.onerror

实例对象的onerror属性，用于指定报错时的回调函数。

socket.onerror = function(event) {
// handle error event
};
​
socket.addEventListener("error", function(event) {
// handle error event
});

五、服务端的实现

WebSocket 服务器的实现，可以查看维基百科的列表。

常用的 Node 实现有以下三种。

• µWebSockets
• Socket.IO
• WebSocket-Node

<<<<<<< HEAD 具体的用法请查看它们的文档，这里不详细介绍了。

Nginx

Nginx的功能

反向代理与正向代理

客户端 -> 代理服务器 -> 服务器

反向代理和正向代理的区别就是：正向代理代理客户端，反向代理代理服务器。

正向代理，客户端知道服务器地址，服务器不知道客户端地址；反向代理，客户端不知道服务器地址，服务器知道客户端地址。

反向代理主要作用

• 对客户端隐藏服务器（集群）的IP地址
• 安全：作为应用层防火墙，为网站提供对基于Web的攻击行为（例如DoS/DDoS）的防护，更容易排查恶意软件等
• 为后端服务器（集群）统一提供加密和SSL加速（如SSL终端代理）
• 负载均衡，若服务器集群中有负荷较高者，反向代理通过URL重写，根据连线请求从负荷较低者获取与所需相同的资源或备援
• 对于静态内容及短时间内有大量访问请求的动态内容提供缓存服务
• 对一些内容进行压缩，以节约带宽或为网络带宽不佳的网络提供服务
• 减速上传
• 为在私有网络下（如局域网）的服务器集群提供NAT穿透及外网发布服务
• 提供HTTP访问认证[2]
• 突破互联网封锁

负载均衡

负载均衡最重要的一个应用是利用多台服务器提供单一服务，这种方案有时也被称为服务器农场。通常，负载平衡主要应用于Web网站，大型的Internet Relay Chat网络，高流量的文件下载网站，NNTP（Network News Transfer Protocol）服务和DNS服务。现在负载平衡器也开始支持数据库服务，称之为数据库负载平衡器。

======= 具体的用法请查看它们的文档，这里不详细介绍了。