一、HTTP 协定

HTTP 协定：超文本传输协定

是一种具体规定了浏览器和万维网 (WWW = World Wide Web) 服务器之间相互通信的规定，通过因特网传送

万维网文档的数据传送协定。HTTP 是基于 TCP 的应用层协定

(OSI 网络七层协定从上到下别离是 应用层、表示层、会话层、传输层、网络层、数据链路层、物理层）

* 申请 / 响应报文

• 连贯建设流程

* HTTP 的特点

A、申请报文和响应报文

1、申请报文

如下:

Host：指明了该对象所在的主机

Connection：Keep-Alive 首部行用来表明该浏览器通知服务器应用继续连贯

Content-Type: x-www-form-urlencoded 首部行用来表明 HTTP 会将申请参数用 key1=val1&key2=val2 的方

式进行组织，并放到申请实体外面

User-agent：首部行用来指明用户代理，即向服务器发送申请的浏览器类型

Accept-lauguage：首部行示意用户想得到该对象的法语版本（如果服务器中有这样的对象的话），否则，

服务器应发送它的默认版本

2、响应报文

如下：

状态码及其相应的短语批示了申请的后果。

一些常见的状态码和对应的短语：

• 200 OK：申请胜利，信息在返回的响应报文中
• 301 Moved Permanently：申请的对象曾经被永恒转移了，新的 URL 定义在响应报文中的 Location：首部行中。客户软件将主动获取新的 URL
• 400 Bad Request：一个通用过错代码，批示该申请不能被服务器了解
• 404 Not Found：被申请的文件不在服务器上
• 505 HTTP Version Not Supported：服务器不反对申请报文应用的 HTTP 协定版本

<4 结尾的状态码通常是客户端的问题，5 结尾的则通常是服务端的问题 >

Connection：close 首部行通知客户，发送完报文后将敞开 TCP 连贯。

Date: 指的不是对象创立或最初批改的工夫，而是服务器从文件系统中检索到该对象，插入到响应报文，

并发送该响应报文的工夫。

Server: 首部行批示该报文是由一台 Apache Web 服务器产生的，相似于 HTTP 申请报文里的 User-agent

Content-Length：首部行批示了被发送对象中的字节数 Content-Type：首部行批示了实体体中的对象是 HTML 文本

二、HTTP 的申请形式

GET、POST、PUT、DELETE、HEAD、OPTIONS

1、GET 和 POST 形式的区别

从语法角度来看，最直观的区别就是

• GET 的申请参数个别以? 宰割拼接到 URL 前面，POST 申请参数在 Body 外面
• GET 参数长度限度为 2048 个字符，POST 个别是没限度的
• GET 申请因为参数袒露在 URL 中，是不平安的，POST 申请则是绝对平安

之所以说是绝对平安，是因为，如果 POST 尽管参数非明文，但如果被抓包，GET 和 POST 一样都是不平安的。(HTTPS 该用还是得用)

而从语义的角度来看：

GET：获取资源是 平安的，幂等的(只读的，纯正的)，可缓存的 POST：获取资源是 非平安的，非幂等的，不可缓存的

* 这里的平安是指不应引起 Server 端的任何状态变动
GET 的语义就是获取数据，是不会引起服务器的状态变动的，即是平安的。（HEAD，OPTIONS 也是平安的）而 POST 语义则是提交数据，是可能会引起服务器状态变动的，即是不平安的

* 幂等: 同一个申请办法执行屡次和执行一次的成果完全相同显然 GET 申请是幂等而 POST 申请是非幂等的。
这里用幂等形容 GET 还不够，因为 GET 不止是执行屡次和执行一次的成果完全相同，而且是执行一次和执行零次的成果也是完全相同的。

* 可缓存的
申请是否能够被缓存。
GET 申请会被动进行 Cache

以上个性，并非并列，正是因为 GET 是幂等的只读的，即 GET 申请除了返回数据不会有其余副作用，所以 GET 才是平安的，从而能够间接由 CDN 缓存，大大加重服务器的累赘，也就是可缓存的。

而 POST 是非幂等的，即除了返回数据还会有其余副作用，所以 POST 是不平安的，必须交由 web 服务器解决，即是 不可缓存的

GET 和 POST 实质上就是 TCP 链接，并无差别。然而因为 HTTP 的规定和浏览器 / 服务器的限度，导致他们在利用过程中体现出一些不同。

在响应时，GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包:
对于 GET 形式的申请，浏览器会把 Header 和实体主体一并发送进来，服务器响应 200（返回数据）；
而对于 POST，浏览器先发送 Header，服务器响应 100 Continue，浏览器再发送实体主体，服务器响应 200 OK（返回数据）。

2、GET 绝对 POST 的劣势是什么？

1、最大的劣势就是不便。GET 的 URL 能够间接手输，从而 GET 申请中的 URL 能够被存在书签里，或者历史记录里

2、能够被缓存，大大加重服务器的累赘
所以大多数状况下，还是用 GET 比拟好。

三、HTTP 的特点

无连贯、无状态

HTTP 的长久连贯、Cookie/Session

1、HTTP 的无状态

即协定对于事务处理没有记忆能力。

每次的申请都是独立的，它的执行状况和后果与后面的申请和之后的申请时无间接关系的，它不会受后面的申请应答状况间接影响，也不会间接影响前面的申请应答状况

也就是说 服务器中没有保留客户端的状态，客户端必须每次带上本人的状态去申请服务器 规范的 HTTP 协定指的是不包含 cookies，session，application 的 HTTP 协定

2、HTTP 的长久连贯

* 非长久连贯：每个连贯解决一个申请 - 响应事务。

* 长久连贯：每个连贯能够解决多个申请 - 响应事务。

长久连贯状况下，服务器收回响应后让 TCP 连贯持续关上着。同一对客户 / 服务器之间的后续申请和响应能够通过这个连贯发送。

HTTP/1.0 应用非长久连贯。HTTP/1.1 默认应用长久连贯 <keep-alive>。

非长久连贯的每个连贯，TCP 得在客户端和服务端调配 TCP 缓冲区，并维持 TCP 变量，会重大减少服务器累赘。而且每个对象都有 2 个 RTT(Round Trip Time，也就是一个数据包从收回去到回来的工夫)的提早，因为 TCP 的拥塞管制计划, 每个对象都蒙受 TCP 缓启动，因为每个 TCP 连贯都起始于缓启动阶段

HTTP 长久连贯怎么判断一个申请是否完结的？

* Content-length：依据所接管字节数是否达到 Content-length 值

* chunked(分块传输):Transfer-Encoding。当抉择分块传输时，响应头中能够不蕴含

Content-Length，服务器会先回复一个不带数据的报文（只有响应行和响应头和 \r\n），而后开始传输若干个数据块。当传输完若干个数据块后，须要再传输一个空的数据块，当客户端收到空的数据块时，则客户端晓得数据接管结束。

四、HTTPS、对称加密、非对称加密

作为一个 iOS 开发者，有一个学习的气氛跟一个交换圈子特地重要，这是一个我的 iOS 开发公众号：编程大鑫，不论你是小白还是大牛都欢送入驻，让咱们一起提高，独特倒退！（群中会无偿分享技术材料）

1、HTTPS 和 HTTP 的区别

HTTPS 协定 = HTTP 协定 + SSL/TLS 协定

SSL 的全称是 Secure Sockets Layer，即安全套接层协定，是为网络通信提供平安及数据完整性的一种平安协定。TLS 的全称是 Transport Layer Security，即平安传输层协定。即 HTTPS 是平安的 HTTP。

2、HTTPS 的连贯建设流程

HTTPS 为了兼顾平安与效率，同时应用了对称加密和非对称加密。在传输的过程中会波及到三个密钥：

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

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

如上图，HTTPS 连贯过程大抵可分为八步:

1、客户端拜访 HTTPS 连贯。

客户端会把平安协定版本号、客户端反对的加密算法列表、随机数 C 发给服务端。

2、服务端发送证书给客户端

服务端接管密钥算法配件后，会和本人反对的加密算法列表进行比对，如果不合乎，则断开连接。否则，服务端会在该算法列表中，抉择一种对称算法（如 AES）、一种公钥算法（如具备特定秘钥长度的 RSA）和一种 MAC 算法发给客户端。

服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密应用的，服务器端保留着私钥，不能将其泄露，公钥能够发送给任何人。

在发送加密算法的同时还会把数字证书和随机数 S 发送给客户端

3、客户端验证 server 证书

会对 server 公钥进行查看，验证其合法性，如果发现发现公钥有问题，那么 HTTPS 传输就无奈持续。

4、客户端组装会话秘钥

如果公钥合格，那么客户端会用服务器公钥来生成一个前主秘钥(Pre-Master Secret，PMS)，并通过该前主秘钥和随机数 C、S 来组装成会话秘钥

5、客户端将前主秘钥加密发送给服务端

是通过服务端的公钥来对前主秘钥进行非对称加密，发送给服务端

6、服务端通过私钥解密失去前主秘钥

服务端接管到加密信息后，用私钥解密失去主秘钥。

7、服务端组装会话秘钥

服务端通过前主秘钥和随机数 C、S 来组装会话秘钥。

至此，服务端和客户端都曾经晓得了用于此次会话的主秘钥。

8、数据传输

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

同理，服务端收到客户端发送来的密文，用服务端密钥对其进行对称解密，失去客户端发送的数据。

总结：

会话秘钥 = random S + random C + 前主秘钥

* HTTPS 连贯建设过程应用非对称加密，而非对称加密是很耗时的一种加密形式

• 后续通信过程应用对称加密，缩小耗时所带来的性能损耗

* 其中，对称加密加密的是理论的数据，非对称加密加密的是对称加密所须要的客户端的密钥。

五、对称加密和非对称加密

1、对称加密

用同一套密钥来进行加密解密。

对称加密通常有 DES,IDEA,3DES 加密算法。

2、非对称加密

用公钥和私钥来加解密的算法。

公钥（Public Key）与私钥（Private Key）是通过一种算法失去的一个密钥对（即一个公钥和一个私钥），公钥是密钥对中公开的局部，私钥则是非公开的局部, 私钥通常是保留在本地。

* 用公钥进行加密，就要用私钥进行解密；反之，用私钥加密，就要用公钥进行解密（数字签名）。

* 因为私钥是保留在本地的，所以非对称加密绝对与对称加密是平安的。
但非对称加密比对称加密耗时(100 倍以上), 所以通常要联合对称加密来应用。

常见的非对称加密算法有：RSA、ECC（挪动设施用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

而为了确保客户端可能确认公钥就是想要拜访的网站的公钥，引入了数字证书的概念，因为证书存在一级一级的签发过程，所以就呈现了证书链，在证书链中的顶端的就是根 CA。

六、TCP 的特点和报文构造

1、面向连贯、牢靠传输、面向字节流、全双工服务

2、TCP 的报文构造

TCP 报文段由 首部字段 和一个 数据字段 组成。

数据字段蕴含一块利用数据。最大报文长度 MSS（Maximum Segment Size）限度了报文段数据字段的最大长度。MSS 选项用于在 TCP 连贯建设时，收发单方协商通信时每一个报文段所能承载的最大数据长度。所以当 TCP 发送一个大文件（比方一张高清图片）时，通常是将该文件划分为 MSS 长度的若干块（最初一块除外，通常会小于 MSS）。而理论交互式利用通常传送长度小于 MSS 的数据块。

如图，与 UDP 一样，首部包含 源端口号 和目标端口号 ，用于多路复用 / 合成来自下层或送到下层利用的数据。TCP 首部也同样包含 测验和字段

TCP 首部还蕴含下列字段:

* 32 比特的 序号字段  Seq(sequence number field) 和 32 比特的 确认号字段 Ack(acknowledge number field)

* 16 比特的 接管窗口字段 RW(receive window field), 该字段用于流量管制，用于批示接管方违心接管的字节数量。

* 4 比特的 首部长度字段（header length field），该字段批示了以 32 比特的字为单位的 TCP 首部长度。因为 TCP 选项字段的起因，TCP 首部长度是可变的。（通常，选项字段为空，所以 TCP 首部的典型长度就是 20 字节）

* 可选和变长的 选项字段（option field），该字段用于发送方和接管方协商最大报文段长度（MSS）时，或用作窗口调节因子时应用。

* 6 比特的 标记字段（flag field）。ACK 比特用于批示确认字段中的值是无效的，即该报文段包含一个对已被接管报文段的确认。RST、SYN、FIN 比特用于连贯建设和拆除。

PSH 比特批示接管方应立即将数据交给下层。URG 比特用于批示报文段里存在着被发送端的下层实体置为“紧急”的数据。紧急数据的最初一个字节由 16 比特的紧急数据指针字段指出。当紧急数据存在并给出指向紧急数据尾的指针的时候，TCP 必须告诉接收端的下层实体。在实践中，PSH、URG 和紧急数据指针并没有应用。

3、序号字段 Seq 和确认号字段 Ack

* 在 TCP 通信中，无论是建设连贯，数据传输，敌对断开，强制断开，都离不开 Seq 值和 Ack 值，它们是 TCP 传输的可靠保证。

序号 Seq：

TCP 把数据看成一个无构造的、有序的字节流。一个 报文段的序号 因而是该报文段的首字节的字节流编号。比方数据流由一个蕴含 100000 字节的文件组成，其 MSS 是 1000 字节，数据流的首字节编号是 0。该 TCP 将为该数据流构建 100 个报文段。给第一个报文段调配序号 0，第二个则是 1000，第三个是 2000，以此类推。每一个序号被填入到相应 TCP 报文段首部的序号字段中。

确认号 Ack：

TCP 是全双工服务的，因而主机 A 在向主机 B 发送数据的同时，兴许也在接管主机 B 的数据。

主机 A 填充进报文段的确认号是主机 A 冀望从主机 B 收到的下一个字节的序号。

在上个例子中，如果服务端曾经接管蕴含字节 0-999 的报文段和蕴含字节 2000-2999 的报文段，但因为某种原因，还未收到蕴含字节 1000-1999 的报文段，那么将仍会期待字节 1000（及其后的字节）。因而服务端发给客户端的下一个报文段将在 确认号 Ack 字段中蕴含 1000。

因为 TCP 只确认该流中至第一个失落字节为止的字节，所以 TCP 被称为 累积确认。

七、三次握手

数据开始传输前，须要通过 三次握手来建设连贯

事实上我认为，这里称说三步握手（three-way handshake）才更贴切些

第一步：

* 客户端的 TCP 首先向服务端的 TCP 发送一条非凡的 TCP 报文段。该报文段不蕴含应用层数据，该报文

段首部中的一个标记位（SYN 比特）被置为 1，所以该报文段被称为 SYN 报文段。另外，客户会随机抉择一个初始序号 client_isn，并将该序号搁置于该起始的 TCP SYN 报文段的序号字段中。

* 客户端和服务端最开始都处于 CLOSED 状态，发送过该 SYN 报文段后，客户端 TCP 进入 SYN_SENT 状态，期待服务端确认并将 SYN 比特置为 1 的报文段。

第二步：

* 收到 SYN 报文段后，服务端会为该 TCP 连贯调配 TCP 缓存和变量，服务端 TCP 会进入 SYN_RCVD 状态，期待客户端 TCP 发送确认报文段。

* 并向该客户端 TCP 发送容许连贯的报文段，该报文段同样不蕴含应用层数据。该报文段首部的 SYN 比特被置为 1，确认号字段被置为 client_isn+1。服务端还会抉择本人的初始序号 server_isn，放到报文段首部的序号段中。该连贯被称为 SYNACK 报文段。

第三步：

* 收到 SYNACK 报文段后，客户端也要为该 TCP 连贯调配缓存和变量，客户端 TCP 进入 ESTABLISHED 状态，在此状态，客户端就能发送和接管蕴含有效载荷数据的报文段了。

* 并向服务端 TCP 发送一个报文段：这最初一个报文段对服务端的容许连贯的报文示意了确认（将 server_isn + 1 放到报文段首部的确认字段中）。因为连贯曾经建设了，所以该 SYN 比特被置为 0。这个阶段，能够在报文段负载中携带应用层数据。

* 收到客户端该报文段后，服务端 TCP 也会进入 ESTABLISHED 状态，能够发送和接管蕴含有效载荷数据的报文段。

八、四次挥手

参加 TCP 连贯的两个过程中的任何一个都能终止该连贯，当连贯完结后，主机中的资源（缓存和变量）会被开释。

上边说到，SYN 和 FIN 标记位别离对应着 TCP 连贯的建设和拆除。

第一步：

* 客户利用过程收回一个敞开连贯的指令。会引起客户端 TCP 向服务端发送一个非凡的 TCP 报文段。该报文段即是将首部的一个标记位 FIN 比特置为 1。

* 同时，客户端进入 FIN_WAIT_1 状态，期待服务端的带有确认的 TCP 报文段。

第二步：

* 收到该报文段后会向客户端发送一个确认报文段。

* 服务端 TCP 进入 CLOSE_WAIT 状态，对应客户端的 TIME_WAIT，示意被动敞开。

* 客户端收到该报文段后，进入 FIN_WAIT_2 状态，期待服务端的 FIN 比特置为 1 的报文段。

第三步：

* 服务端发送本人的终止报文段，同样是把报文段首部的标记位 FIN 比特置为 1。

* 服务端 TCP 进入 LAST_ACK 状态，期待服务端最初的确认报文段。

第四步：

* 客户端收到服务端的终止报文段后，向服务端发送一个确认报文段。同时，客户端进入 TIME_WAIT 状态。

* 如果 ACK 失落，TIME_WAIT 状态使 TCP 客户重传最初的确认报文，TIME_WAIT 通常会期待 2MSL（Maximum Segment Lifetime 最长报文段寿命）。通过期待后，连贯就正式敞开，从新进入 CLOSED 状态，客户端所有资源将被开释。

* 服务端收到该报文段后，同样也会敞开，从新进入 CLOSED 状态，开释所有服务端 TCP 资源。

一些问题

1、问：为什么建设连贯只用三次握手，而断开连接却要四次挥手？

* 首先，当客户端数据已发送结束，且晓得服务端也全副接管到了时，就会去断开连接即向服务端发送 FIN

* 服务端接管到客户端的 FIN，为了示意接管到了，就会向客户端发送 ACK

* 但此时，服务端可能还在发送数据，并没有敞开 TCP 窗口的意思，所以服务端的 FIN 和 ACK 并不是同步发的，只有当数据发送完了，才会发送 FIN

* 答：服务端的 FIN 和 ACK 须要分开发，并不是像三次握手中那样，SYN 能够和 ACK 同步发，所以就须要四次挥手

2、在四次挥手中，客户端为什么在 TIME_WAIT 后必须期待 2MSL 工夫呢？

这个 ACK 报文段有可能失落，因此使处在 LAST_ACK 端的服务端收不到对已发送的 FIN 报文段的 ACK 报文段，从而服务端会去一直重传 FIN 报文段。
而客户端就能在 2MSL 工夫内收到重传的 FIN 报文段。接着客户端重传一次确认，重新启动 2MSL 计时器。
直至服务端收到后，客户端和服务端就都会进入 CLOSED 状态，敞开 TCP 连贯。
而如果客户端不期待 2MSL 工夫，而是在发送完 ACK 确认后立刻开释资源，敞开连贯，那么就无奈收到服务端重传的 FIN 报文段，因此也不会再发送一次 ACK 确认报文段，这样，服务端就无奈失常进入 CLOSED 状态，资源就始终无奈开释了。

•  答：为了保障客户端发送的最初一个 ACK 报文段可能达到服务端。

3、TCP 在创立连贯时，为什么须要三次握手而不是两次或四次？

一个简略的例子：

* 三次握手：

“喂，你听失去吗？”

“我听失去呀，你听失去我吗？”

“我能听到你，明天 balabala……”

* 两次握手：

“喂，你听失去吗？”

“我听失去呀，你听失去我吗？”“喂，你听失去吗？”“……谁在谈话？”“喂，你听失去吗？”

“……”

* 四次握手：

“喂，你听失去吗？”

“我听失去呀”“你能听到我吗？”“……不想跟傻逼谈话”

之所以不必四次握手的起因很容易了解，就是浪费资源，服务端的 SYN 和 ACK 能够一起发，齐全没必要离开两次。

而如果是两次握手：

客户端收回的第一个连贯申请 SYN 报文段并没有失落，而是在某个网络结点长时间的滞留了，以至延误到连贯开释当前的某个工夫才达到服务端。原本这是一个早已生效的报文段。但服务端收到此生效的连贯申请 SYN 报文段后，就误认为是客户端再次收回的一个新的连贯申请 SYN 报文段。于是就向客户端收回 ACK 确认报文段，批准建设连贯。假如不采纳三次握手，那么只有服务端收回确认，新的连贯就建设了。

因为当初客户端并没有收回建设连贯的 SYN 申请，因而不会理会服务端的确认，也不会向服务端发送数据。但服务端却认为新的运输连贯曾经建设，并始终期待客户端发来数据。这样，服务端的很多资源就白白浪费掉了。

事实上：TCP 对有数据的 TCP 报文段必须确认的准则，所以，客户端对服务端的 SYN 报文段必须回复一个 ACK 报文段示意确认。并且，TCP 不会为没有数据的 ACK 超时重传，那么当服务端没收到客户端的 ACK 确认报文段时，会超时重传本人的 SYN 报文段，始终到收到客户端的 ACK 为止。

* 答：两次握手会可能导致已生效的连贯申请报文段忽然又传送到了服务端产生谬误，四次握手又太浪费资源

代码实现

参考 UDP 的代码，其实 TCP 在代码实现上也很类似，首先·socket·初始化时不再用·SOCK_DGRAM·，而是用·SOCK_STREAM·

TCP 服务端要多了一道监听、承受连贯的过程：

UDP 则是多了一道连贯的过程：

而后就是在接管和发送数据时，不必再传主机和端口了。即由 recvfrom、sendto 改为 recv 和 send。

python 的客户端代码如下：

服务端代码：

九、牢靠数据传输

网络层服务（IP 服务）是不牢靠的。IP 不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。

TCP 则是在 IP 服务上创立了一种 牢靠数据传输服务

TCP 的 牢靠数据传输服务 确保一个过程从其接管缓存中读出的数据流是无损坏、无距离、无冗余、按序的

数据流。即该字节流与连贯的另一端收回的字节流是完全相同的。

作为 TCP 接管方，有三个与发送和重传无关的次要事件

1、从下层利用数据接收数据

将数据封装到一个报文段中，并把报文段交付给 IP。每个报文段都蕴含一个序号 Seq，即该报文段第一个数据字节的字节流编号。如果定时器还没有为其余报文段而运行，则启动定时器(即不是每条报文段都会启动一个定时器，而是一共只启动一个定时器)，定时器的过期间隔是 TimeoutInterval

是由 EstimatedRTT 和 DevRTT 计算得来的:TCP 的往返工夫的预计与超时

2、超时

TCP 通过重传引起超时的报文段来响应超时事件，而后重启定时器。

而发送端超时有两种状况：发送数据超时，接收端发送 ACK 超时。这两种状况都会导致发送端在 TimeoutInterval 内接管不到 ACK 确认报文段。

* 1、如果是发送数据超时，间接重传即可。

* 2、而如果是接收端发送 ACK 超时，这种状况接收端实际上曾经接管到发送端的数据了。那么当发送端超时重传时，接收端会抛弃重传的数据，同时再次发送 ACK。

而如果在 TimeoutInterval 后接管到了 ACK，会收下 ACK，但不做任何解决

* TCP 不会为没有数据的 ACK 超时重传以下两种状况：

* 1、如果在发送两条或多条数据报文段都超时，那么只会重传序号最小的那个，并重启定时器。只有其余报文段的 ACK 在新重启的定时器超时前达到，就不会重传。

* 2、如果发送序号为 100 和 120 的两条数据报文段，序号 100 的 ACK 失落，但收到了序号 120 的 ACK，因为累积确认机制，能够得出接管方曾经接管到了序号 100 的报文段，这种状况也不会去重传。

3、接管到 ACK

用 TCP 状态变量 SendBase 指最早未被确认的字节的序号。则 SendBase – 1 指接管方已正确按序接管到的数据的最初一个字节的序号。

当收到 ACK 确认报文段后，会将 ACK 的值 Y 与 SendBase 比拟。TCP 采纳 累计确认 的办法，所以 Y 确认来字节编号在 Y 之前的所有字节都曾经收到。如果 Y 比 SendBase 小，不必理睬；而如果 Y 比 SendBase

大，则该 ACK 是在确认一个或多个先前未被确认的报文段，因而要更新 SendBase 变量，如果以后还有未被确认的报文段，TCP 还要重启定时器。

通过超时重传，能保障接管到的数据是无损坏、无冗余的数据流，但并不能保障按序。

而通过 TCP 滑动窗口，可能无效保障接收数据有序

十、流量管制

TCP 连贯的单方主机都会为该 TCP 连贯调配缓存和变量。当该 TCP 连贯收到正确、按序的字节后，就将数据放入接管缓存。下层的利用过程会从该缓存中读取数据，但不用是数据一达到就立刻读取，因为此时应用程序可能在做其余事务。而如果应用层读取数据绝对迟缓，而发送方发送得太多、太快，发送的数据就会很容易地使该连贯的接管缓存溢出。

所以，TCP 为应用程序提供了 流量管制服务（flow-control service），以打消发送方使接管方缓存溢出的可能性。

流量管制是一个速度匹配服务，即发送方的发送速率与接管方应用程序的读取速率相匹配。

作为全双工协定，TCP 会话的单方都各自保护一个 发送窗口 和一个 接管窗口（receive window）的变量来提供流量管制。而发送窗口的大小是由对方接管窗口来决定的，接管窗口用于给发送方一个批示 – 该接管方还有多少可用的缓存空间。

1、发送窗口

发送方的发送缓存内的数据都能够被分为 4 类:

* 已发送，已收到 ACK

* 已发送，未收到 ACK

* 未发送，但容许发送

* 未发送，但不容许发送

则 2 和 3 属于发送窗口

* 发送窗口只有收到发送窗口内字节的 ACK 确认，才会挪动发送窗口的左边界

2、接管窗口

接管方的缓存数据分为 3 类：

1. 已接管

2. 未接管但筹备接管

3. 未接管而且不筹备接管

则 2 属于接管窗口（这里的接管指接收数据并确认）

* 接管窗口只有在后面所有的报文段都确认的状况下才会挪动左边界。当在后面还有字节未接管但收到前面字节的状况下，会先接管下来，接管窗口不会挪动，并不对后续字节发送 ACK 确认报文，以此确保发送端会对这些数据重传。

咱们定义以下变量：

* LastByteRead：接管方应用程序读取的数据流的最初一个字节编号。能够得悉，这是接管缓存的终点

* LastByteRcvd：从网络中达到的并且已放入接管缓存中的数据流的最初一个本人的的编号。

能够得悉：LastByteRcvd – LastByteRead <= RcvBuffer(接管缓存大小)那么接管窗口 rwnd =RcvBuffer –（LastByteRcvd – LastByteRead）
rwnd 是随工夫动态变化的，如果 rwnd 为 0，则意味着接管缓存曾经满了。

接收端在回复给发送端的 ACK 中会蕴含该 rwnd，发送端则会依据 ACK 中的接管窗口的值来管制发送窗口。

有一个问题，如果当发送 rwnd 为 0 的 ACK 后，发送端进行发送数据。期待一段时间后，接管方应用程序读取了一部分数据，接收端能够持续接收数据，于是给发送端发送报文通知发送端其接管窗口大小，但这个报文可怜失落了，咱们晓得，不含数据的 ACK 是不会超时重传的，于是就呈现发送端期待接收端的 ACK 告诉 || 接收端期待发送端发送数据的死锁状态。

为了解决这种问题，TCP 引入了继续计时器（Persistence timer），当发送端收到对方的 rwnd=0 的 ACK 告诉时，就启用该计时器，工夫到则发送一个 1 字节的探测报文，对方会在此时回应本身的接管窗口大小，如果后果仍未 0，则重设继续计时器，持续期待。

十一、拥塞管制

TCP 除了牢靠传输服务外，另一个要害局部就是拥塞管制。

TCP 让每一个发送方依据所感知到的网络拥塞水平来限度其能向连贯发送流量的速率。

可能有三个疑难：

1、TCP 发送方如何感知网络拥塞？

2、TCP 发送方如何限度其向连贯发送流量的速率？

3、发送方感知到网络拥塞时，采纳何种算法来扭转其发送速率？

这就是 TCP 的 拥塞管制机制。

前边说到，TCP 连贯的每一端都是由一个接管缓存、一个发送缓存和几个变量（LastByteRead、LastByteRcvd、rwnd 等）组成。而运行在发送方的 TCP 拥塞管制机制会跟踪一个额定的变量，即 拥塞窗口 cwnd（congestion window）。它对一个 TCP 发送方能向网络中发送流量的速率进行了限度。

发送方中未被确认的数据量不会超过 cwnd 和 rwnd 的最小值:min(rwnd,cwnd)

1、TCP 发送方如何感知网络拥塞？

冗余 ACK（duplicate ACK）：就是再次确认某个报文段的 ACK，而发送方先前曾经收到对该报文段的确认。

冗余 ACK 的产生起因：

* 1. 当接收端接管到失序报文段时，即该报文段序号大于下一个冀望的、按序的报文段，检测到数据流中的距离，即由报文段失落，并不会对该报文段确认。TCP 不应用否定确认，所以不能向发送方发送显式的否定确认，为了使接管方得悉这一景象，会对上一个按序字节数据进行反复确认，这也就产生了一个冗余 ACK。

* 2. 因为发送方常常发送大量的报文段，如果其中一个报文段失落，可能在定时器过期前，就会收到大量的冗余 ACK。一旦收到 3 个冗余 ACK（3 个以下很可能是链路层的乱序引起的，无需解决），阐明在这个已被确认 3 次的报文段之后的报文段曾经失落，TCP 就会执行 疾速重传，即在该报文段的定时器过期之前重传失落的报文段。

将 TCP 发送方的丢包事件定义为：要么呈现超时，要么收到来自接管方的 3 个冗余 ACK。

当呈现适度的拥塞时，路由器的缓存会溢出，导致一个数据报被抛弃。抛弃的数据报接着会引起发送方的丢包事件。那么此时，发送方就认为在发送方到接管方的门路上呈现了网络拥塞。

2、TCP 发送方如何限度其向连贯发送流量的速率？

* 当呈现丢包事件时：该当升高 TCP 发送方的速率。

* 当对先前未确认报文段的确认达到时，即接管到非冗余 ACK 时，该当减少发送方的速率。

3、发送方感知到网络拥塞时，采纳何种算法来扭转其发送速率？

即 TCP 拥塞控制算法（TCP congestion control algorithm）

包含三个次要局部：慢启动、拥塞防止、疾速复原，其中疾速复原并非是发送方必须的，慢启动和拥塞防止则是 TCP 强制要求的

* 慢启动

当一条 TCP 连贯开始时，拥塞窗口 cwnd 的值通常置为一个 MSS 的较小值，这就使初始发送速率大概为 MSS/RTT（RTT：往返时延，报文段从收回到对该报文段的确认被接管之间的工夫量）。
而对 TCP 发送方来说，可用带宽可能比 MSS/RTT 大得多,TCP 发送方心愿迅速找到可用带宽的数量。
因而，在慢启动状态，cwnd 以一个 MSS 的值开始并且每当收到一个非冗余 ACK 就减少一个 MSS。

最后 cwnd 值为 1MSS，发送一个报文段 M1。收到 M1 的确认后，cwnd 减少为 2MSS，这时能够发送两个

报文段 M2，M3。收到这两个报文段的确认后，cwnd 则减少为 4MSS，能够发送四个报文段，以此类推 …

因而，TCP 尽管发送速率起始慢，但在慢启动阶段以指数增长。

这种指数增长很显然不是无限度的，那么何时完结呢？
如果呈现丢包事件，TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2

* 产生由超时引起的丢包事件，并将 cwnd 重置为 1MSS，重启慢启动

* 当 TCP 发送方的 cwnd 值达到或超过 ssthresh，再持续翻倍显然不适合。这时将完结慢启动转移到拥塞防止模式。

* TCP 发送方检测到 3 个冗余 ACK，会完结慢启动，并疾速重传，即在该报文段的定时器过期之前重传失落的报文段。且进入疾速复原状态。

十二、拥塞防止

一旦进入拥塞防止状态，cwnd 的值大概是上次遇到拥塞时的值的一半，即间隔拥塞并不边远。因而，TCP 无奈每过一个 RTT 就将 cwnd 翻倍。而是每个 RTT 只减少 1MSS，即每收到一个非冗余 ACK，就将 cwnd 减少 1 /cwnd。即如果此时 cwnd 为 10MSS，则每收到一个非冗余 ACK，cwnd 就减少 1/10MSS，在 10 个报文段都收到确认后，拥塞窗口的值就减少了 1MSS。

那么何时完结拥塞防止的线性增长（每 RTT 1MSS）呢？
和慢启动一样，如果呈现丢包事件，TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2（加法增大，乘法减小）

* 产生由超时引起的丢包事件，拥塞防止和慢启动解决的形式雷同。即 TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2，并将 cwnd 重置为 1MSS，重启慢启动

* TCP 发送方检测到 3 个冗余 ACK，cwnd 为原来的一半加上 3MSS，进入疾速复原状态。

十三、疾速复原

疾速复原是由 3 个冗余 ACK 引起的。
在疾速复原中，对引起 TCP 进入疾速复原状态的缺失报文段，对收到的每个冗余 ACK，cwnd 减少 1 个 MSS。
最终，当对失落报文段的一个 ACK 达到时，TCP 在升高 cwnd 后进入拥塞防止状态。
如果呈现超时，和之前一样，即 TCP 发送方将 ssthresh（慢启动阈值）设置为 cwnd/2，并将 cwnd 重置为 1MSS，重启慢启动

疾速复原并非是必须的。

TCP 的拥塞管制是：每个 RTT 内 cwnd 线性（加性增）减少 1MSS，而后呈现 3 个冗余 ACK 事件时 cwnd 减半（乘性减），因而 TCP 拥塞管制常被称为 加性增，乘性减 拥塞管制形式。

十四、DNS

因特网上的主机，能够应用多种形式标识，比方主机名或 IP 地址。

* 一种标识办法就是用它的 主机名（hostname），比方 ·<u>www.baidu.com</u>、<u>www.google.com</u>、<u>gaia.cs.umass.edu</u> 等。这形式不便人们记忆和承受，然而这种长度不一、没有法则的字符串路由器并不不便解决。

* 还有一种形式，就是间接应用定长的、有着清晰层次结构的 IP 地址，路由器比拟热衷于这种形式。
为了折衷这两种形式，咱们须要一种能进行主机名到 IP 地址转换的目录服务。这就是 域名零碎（Domain Name System，DNS）的次要工作。

DNS 是：

1、一个由分层的 DNS 服务器 实现的分布式数据库

2、一个使得主机可能查问分布式数据库的 应用层协定

而 DNS 服务器通常是运行 BIND 软件的 UNIX 机器，DNS 协定运行在 UDP 上，应用 53 号端口
DNS 通常是由其余应用层协定所应用的，包含 HTTP、SMTP 等。其作用则是： 将用户提供的主机名解析为 IP 地址

DNS 的一种简略设计就是在因特网上只应用一个 DNS 服务器，该服务器蕴含所有的映射。很显著这种设计是有很大的问题的：

单点故障：如果该 DNS 服务器解体，全世界的网络随之瘫痪

通信容量：单个 DNS 服务器必须解决所有 DNS 查问

远距离的集中式数据库：单个 DNS 服务器必须面对所有用户，间隔过远会有重大的时延。

保护：该数据库过于宏大，还须要对新增加的主机频繁更新。

所以，DNS 被设计成了一个 分布式、层次数据库

十五、DNS 服务器

为了解决扩展性问题，DNS 应用了大量的 DNS 服务器，它们以档次形式组织，并且散布在全世界范畴内。

域名服务器是提供域名解析的服务器，在有根本的常识下，任何人都能够搭建域名服务器，甚至是根域名服务器，有名的软件有：BIND

目前的 DNS 服务器大抵分为 3 种类型的 DNS 服务器：根 DNS 服务器、顶级域 DNS 服务器、权威 DNS 服务器

1、根 DNS 服务器

因特网上有 13 个根 DNS 服务器（标号 A 到 M），1 个为主根服务器在美国。其余 12 个均为辅根服务器，其中 9 个在美国，欧洲 2 个，位于英国和瑞典，亚洲 1 个位于日本。这里的个并不是指物理意义上的单个服务器，它是一个逻辑概念，根 DNS 服务器能够由散布在寰球的多个服务器组成，造成一个集群，对外对立为 1 台逻辑的根 DNS 服务器（即每个标号下的根 DNS 服务器的 IP 地址是一样的）。而理论物理意义上的根 DNS 服务器，已超过千台

<u>https://root-servers.org/</u> 这里能够查到所有根 DNS 服务器的散布

截止发这篇文章之前，中国有 19 台根 DNS 服务器，别离位于：

* 北京：F，I，J，L

* 杭州：J

* 澳门：F

* 香港：A、D、E、F、F、I、J

* 台北：E、F、F、I、K、L

2、顶级域（TLD）DNS 服务器

这些服务器负责顶级域名如 com、org、net、edu 和 gov，以及所有国家的顶级域名如 uk、fr、ca 和 cn

3、权威 DNS 服务器

在因特网上具备公共可拜访主机的每个组织机构必须提供公共可拜访的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。一个组织机构的权威 DNS 服务器珍藏了这些 DNS 记录。

除此之外，还有一种很重要的 DNS，成为 本地 DNS 服务器，其严格来说不属于该服务器的层次结构，但它

对 DNS 层次结构是重要的。每个 ISP（互联网服务提供商），比方一个大学，一个公司或一个居民区的 ISP，都有一台本地 DNS 服务器。

十六、DNS 解析过程

1、迭代查问和递归查问

很清晰地显示出了一条 DNS 查问链：本地 DNS 服务器 –> 根 DNS 服务器 –> 顶级域 DNS 服务器 –> 权威 DNS 服

务器，所有查问都是递归的。

这是 递归查问。

这种利用了 迭代查问 和递归查问 ，从 Client 与本地 DNS 之间是 递归查问 ，其余则是 迭代查问。

所谓 递归查问 过程 就是“查问的递交者”更替, 而 迭代查问 过程 则是“查问的递交者”不变。

从实践上讲，任何 DNS 查问既能够是迭代的也能是递归的。

而在理论过程中，更罕用的是图上 从申请主机到本地 DNS 服务器的查问是递归，其余查问是迭代的 这种形式。

2、DNS 缓存

DNS 缓存（DNS Caching）：为了改善时延性能并缩小在因特网上到处传输的 DNS 报文数量，DNS 宽泛应用了缓存技术。

在一个申请链中，当某 DNS 服务器接管一个 DNS 答复时，它能将该答复中的信息缓存在本地存储器中。那么另一个对雷同主机名的查问达到该 DNS 服务器时，该 DNS 服务器就能够提供所要求的 IP 地址，即便它不是该主机名的权威服务器。

因为 IP 和主机名的映射并不是永恒的，DNS 服务器在一段时间后就会抛弃缓存的信息。

本地 DNS 服务器也可能缓存 TLD 服务器的 IP 地址，从而容许本地 DNS 绕过查问链中的根 DNS 服务器。

而事实上，有 DNS 的中央，就有缓存。浏览器、操作系统、本地 DNS 服务器、根 DNS 服务器，它们都会对 DNS 后果做肯定水平的缓存。 

3、DNS 解析过程

大抵分为 8 步：

* 1、发动基于域名的申请后，首先查看本地缓存（浏览器缓存 –> 操作系统的 hosts 文件）

* 2、如果本地缓存中有，间接返回指标 IP 地址，否则将域名解析申请发送给本地 DNS 服务器

* 3、如果本地 DNS 服务器中有，间接返回指标 IP 地址，到这一步根本能解析 80% 的域名。如果没有，本地 DNS 服务器将解析申请发送给根 DNS 服务器

* 4、根 DNS 服务器会返回给本地 DNS 服务器一个所查问的 TLD 服务器地址列表

* 5、本地 DNS 服务器再向上一步返回的 TLD 服务器发送申请，TLD 服务器查问并返回域名对应的权威域名服务器的地址

* 6、本地 DNS 服务器再向上一步返回的权威域名服务器发送申请，权威域名服务器会查问存储的域名和 IP 的映射关系表，将 IP 连同一个 TTL（过期工夫）值返回给本地 DNS 服务器

* 7、本地 DNS 服务器会将 IP 和主机名的映射保存起来，保留工夫由 TTL 来管制

* 8、本地 DNS 服务器把解析的后果返回给用户，用户依据 TTL 值缓存在本地零碎缓存中，域名解析过程完结

十七、DNS 记录和报文

1、资源记录

所有 DNS 服务器都存储了 资源记录（Resource Record，RR），其提供了主机名到 IP 的映射。
资源记录是一个蕴含以下字段的四元组：

（Name，Value，Type，TTL）

TTL 是该记录的生存工夫，决定了资源记录该当从缓存中删除的工夫。

Name 和 Value 的值取决于 Type(以下波及的 foo,bar 均为伪变量)：

* Type = A，则 Name 是主机名，Value 使其对应的 IP 地址。这也是一个规范的主机名到 IP 地址的映射。如(replay1.bar.foo.com,145.37.93.126,A)

* Type = NS，则 Name 是个域（如 foo.com），而 Value 是个晓得如何获取该域中主机 IP 地址的权威
DNS 服务器的主机名，如(foo.com,dns.foo.com,NS)

* Type = CNAME, 则 Name 是别名为 Name 的主机对应的标准主机名。该记录可能向查问的主机提供一个主机名对应的标准主机名，如（foo.com,replay1.bar.foo.com,CNAME）

* Type = MX，则 Value 是个别名为 Name 的邮件服务器的标准主机名。如（foo.com,main.bar.foo.com,MX）

2、DNS 报文

DNS 只有查问和答复两种报文，这两种报文格式是一样的。

* 前 12 个字节是 首部区域。

标识符用于标识该查问，这个标识符会被复制到对查问的答复报文中，以便让客户用它来匹配发送的申请和接管到的答复。

标记字段中含有若干标记。1 比特的“查问 / 答复”标记位指出报文是查问报文（0）还是答复报文（1）。当某 DNS 服务器是所申请名字的权威 DNS 服务器时，1 比特的“权威的”标记位被置在答复报文中。此外，还有“心愿递归”、“递归可用”等标记位。

在首部中，还有 4 个数量相干的字段，指出来在首部后的 4 类数据区域呈现的数量，其中 RR 是资源记录的意思。

* 问题区域 蕴含着正在进行的查问信息。该区域包含：名字字段，指出正在被查问的主机名字；类型字段，指出无关该名字的正被查问的问题类型，即上边说的四元组中的 Type

* 答复区域 蕴含了对最后申请的名字的资源记录。在答复区域中能够蕴含多条 RR，因而一个主机名实践上可能有多个 IP 地址（不同用户在不同地点拜访同一个域名，可能会拜访到不同的 IP 地址）

* 权威区域 中蕴含了其余权威服务器的记录

* 附加区域 蕴含了其余有帮忙的记录

得悉 DNS 的报文格式后，咱们也就能够手动发送 DNS 查问包了。

十八、DNS 解析平安问题

1、DNS 劫持

一种可能的域名劫持形式即黑客侵入了宽带路由器并对终端用户的本地 DNS 服务器进行篡改，指向黑客本人伪造的本地 DNS 服务器，进而通过管制本地 DNS 服务器的逻辑返回谬误的 IP 信息进行域名劫持。

另一方面，因为 DNS 解析次要是基于 UDP 协定，除了上述攻击行为外，攻击者还能够监听终端用户的域名解析申请，并在本地 DNS 服务器返回正确后果之前将伪造的 DNS 解析响应传递给终端用户，进而管制终端用户的域名拜访行为。

2、缓存净化（DNS 净化）。

咱们晓得在接管到域名解析申请时，本地 DNS 服务器首先会查找缓存，如果缓存命中就会间接返回缓存后果，不再进行递归 DNS 查问。这时候如果本地 DNS 服务器针对局部域名的缓存进行更改，比方将缓存后果指向第三方的广告页，就会导致用户的拜访申请被疏导到这些广告页地址上。

3、如何解决 DNS 劫持？

DNS 解析产生在 HTTP 协定之前，DNS 解析和 DNS 劫持和 HTTP 没有关系，DNS 协定应用的是 UDP 协定向服

务器的 53 端口进行申请。

要想解决 DNS 劫持：

* 能够应用 HttpDNS 的计划：应用 HTTP 协定向 DNS 服务器的 80 端口进行申请, 来躲避 DNS 劫持

* 在终端上，能够更换 DNS 服务器，不论手机还是电脑，都能手动配置 DNS

十九、Cookie

这里有说到，HTTP 协定是无状态的，服务器中没有保留客户端的状态，客户端必须每次带上本人的状态去申请服务器

基于 HTTP 这种特点，就产生了 cookie/session

1、用户与服务器的交互：Cookie

cookie 次要是用来记录用户状态，辨别用户，状态保留在客户端。

* 1. 首次拜访 amazon 时，客户端发送一个 HTTP 申请到服务器端。服务器端发送一个 HTTP 响应到客户端，其中蕴含 Set-Cookie 头部

* 2. 客户端发送一个 HTTP 申请到服务器端，其中蕴含 Cookie 头部。服务器端发送一个 HTTP 响应到客户端

* 3. 隔段时间再去拜访时，客户端会间接发蕴含 Cookie 头部的 HTTP 申请。服务器端发送一个 HTTP 响应到客户端

cookie 技术有 4 个组件：

* 1. 在 HTTP 响应报文中的一个 cookie 首部行

* 2. 在 HTTP 申请报文中的一个 cookie 首部行

* 3. 在用户端零碎中保留一个 cookie 文件，并由用户的浏览器进行治理

* 4. 位于 Web 站点的一个后端数据库

也就是说，cookie 性能须要浏览器的反对。如果浏览器不反对 cookie（如大部分手机中的浏览器）或者把 cookie 禁用了，cookie 性能就会生效。

2、cookie 的批改和删除

在批改 cookie 的时候，只须要新 cookie 笼罩旧 cookie 即可，在笼罩的时候，因为 Cookie 具备不可跨域名性，留神 name、path、domain 需与原 cookie 统一

删除 cookie 也一样，设置 cookie 的过期工夫 expires 为过来的一个工夫点，或者 maxAge = 0(Cookie 的有效期, 单位为秒)即可

3、cookie 的平安

事实上，cookie 的应用存在争议，因为它被认为是对用户隐衷的一种侵害，而且 cookie 并不平安
HTTP 协定不仅是无状态的，而且是不平安的。应用 HTTP 协定的数据不通过任何加密就间接在网络上流传，有被截获的可能。应用 HTTP 协定传输很秘密的内容是一种隐患。

* 如果不心愿 Cookie 在 HTTP 等非平安协定中传输，能够设置 Cookie 的 secure 属性为 true。浏览器只会在 HTTPS 和 SSL 等平安协定中传输此类 Cookie。

* 此外，secure 属性并不能对 Cookie 内容加密，因此不能保障相对的安全性。如果须要高安全性，须要在程序中对 Cookie 内容加密、解密，以防泄密。

* 也能够设置 cookie 为 HttpOnly，如果在 cookie 中设置了 HttpOnly 属性，那么通过 js 脚本将无奈读取到 cookie 信息，这样能无效的避免 XSS（跨站脚本攻打）攻打

二十、Session

除了应用 Cookie，Web 应用程序中还常常应用 Session 来记录客户端状态。Session 是服务器端应用的一种记录客户端状态的机制，应用上比 Cookie 简略一些，相应的也减少了服务器的存储压力。

Session 是另一种记录客户状态的机制，不同的是 Cookie 保留在客户端浏览器中，而Session 保留在服务器上。

客户端浏览器拜访服务器的时候，服务器把客户端信息以某种模式记录在服务器上。这就是 Session。客户端浏览器再次拜访时只须要从该 Session 中查找该客户的状态就能够了。

* 当程序须要为某个客户端的申请创立一个 session 时，服务器首先查看这个客户端的申请里是否已蕴含了一个 session 标识（称为 SessionId）

* 如果已蕴含则阐明以前曾经为此客户端创立过 session，服务器就依照 SessionId 把这个 session 检索进去，应用（检索不到，会新建一个）

* 如果客户端申请不蕴含 SessionId，则为此客户端创立一个 session 并且生成一个与此 session 相关联的 SessionId，SessionId 的值应该是一个既不会反复，又不容易被找到法则以仿造的字符串，这个 SessionId 将被在本次响应中返回给客户端保留。

* 保留这个 SessionId 的形式能够采纳 cookie，这样在交互过程中浏览器能够主动的依照规定把这个标识发送给服务器。但 cookie 能够被人为的禁止，则必须有其余机制以便在 cookie 被禁止时依然可能把 SessionId 传递回服务器。

二十一、Cookie 和 Session 的区别

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

2、cookie 相比 session 不是很平安，他人能够剖析寄存在本地的 cookie 并进行 cookie 坑骗, 思考到平安该当应用 session。

3、session 会在肯定工夫内保留在服务器上。当拜访增多，会比拟占用你服务器的性能, 思考到加重服务器性能方面，该当应用 cookie。

4、单个 cookie 保留的数据不能超过 4K，很多浏览器都限度一个站点最多保留 20 个 cookie。而 session 存储在服务端，能够无限量存储

5、所以：将登录信息等重要信息寄存为 session; 其余信息如果须要保留，能够放在 cookie 中

二十二、IP 协定

IP 协定是 TCP/IP 外围协定。

1、IP 协定的数据报格局（IPv4）

* 版本号
规定了数据报的 IP 协定版本（IPv4 还是 IPv6）。不同的 IP 版本应用不同的数据报格局，上图是 IPv4 的数据报格局

* 首部长度
大多数 IP 数据报不蕴含选项，所以个别 IP 数据报具备 20 字节的首部。

* 服务类型
使不同类型的 IP 数据报能互相区别开来。

* 数据报长度

整个 IP 数据报的长度，利用首部长度和总长度就能够是算出 IP 数据报中数据内容的起始地址。
该字段长度为 16 比特，所以 IP 数据报最长可达 2^16=65535 字节，而事实上，数据报很少有超过 1500 字节的

* 标识、标记、片偏移字段
这三个字段与 IP 分片无关。此外，IPv6 不容许在路由器上对分组分片

* 生存工夫 TTL
用来确保数据报不会永远在网络中循环。设置该数据报能够通过的最多的路由器数。指定了数据报的生存工夫，通过一个路由器，它的值就减 1，当该字段为 0 时，数据报就被抛弃

* 协定
该字段只有在一个 IP 数据报达到其目的地才有用。该字段值批示了 IP 数据报的数据局部应交给哪个特定的传输层协定，比方，值为 6 表明要交给 TCP，而值为 17 则表明要交给 UDP 首部测验和与 UDP/TCP 的测验和不同，这个字段只测验数据报的首部，不包含数据局部。

* 选项字段
是一个可变长字段，选项字段始终以 4 字节作为界线。这样就能够保障首部始终是 4 字节的整数倍。很少被用到

* 源 IP 和目标 IP

二十三、IP 数据报分片

一个链路层帧能承载的最大数据量叫做最大传送单元（Maximun Transmission Unit,MTU）, 即链路层的 MTU

限度着 IP 数据报的长度。

问题是在不同的链路上，可能应用不同的链路层协定，且每种协定可能具备不同的 MTU。

假设在某条链路上收到一个 IP 数据报，通过查看转发表确定出链路，且出链路的 MTU 比该 IP 数据报的长度要小，如何将这个过大的 IP 数据报压缩进链路层帧的有效载荷字段呢？

解决方案就是 分片 ：将 IP 数据报中的数据分片为两个或更多个较小的 IP 数据报，用独自的链路层帧封装这些较小的 IP 数据报，而后向出链路上发送这些帧，每个这些较小的数据都称为 片（fragment）。

片在达到目的地传输层前须要从新组装。

实际上，TCP 和 UDP 都心愿从网络层上收到残缺的未分片的报文。IPv4 的数据报重组工作是在端系统中，而不是在网络路由器中。

当一台目标主机从雷同源收到一系列数据时，须要确定这些数据报中的某些是否是一些原来较大的数据报中的片。而如果是片的话，须要进一步确定何时收到最初一片，并且如何将这些片拼接到一起以造成初始的数据报。从而就用到了前边说到的 IPv4 数据报首部中的标识、标记、片偏移 字段。

* 1、当生成一个数据报时，发送主机在为该数据报设置源和目标地址的同时在贴上标识号, 发送主机通常将为它发送的每个数据报标识号加 1

* 2、当某路由器须要对一个数据报分片时，造成的每个数据报（即片）具备初始数据报的源地址、目标地址和标识号

* 3、当目的地从同一发送主机收到一系列数据报时，它可能检查数据报的标识号以确定哪些数据报实际上是同一较大数据报的片

* 4、因为 IP 协定是不牢靠服务，一个或者多个片可能永远达到不了目的地。为了让目标主机相对置信它已收到初始数据报的最初一个片，最初一个片的标记比特被设为 0，其余被设为 1

* 5、为了让目标主机确定是否失落了一个片，并且能依照正确的程序从新组装片，应用偏移字段指定该片应放在初始 IP 数据报的哪个地位 >

此外，如果有一个片或者多个片未能达到，则该不残缺的数据报将会被抛弃且不会交给传输层。但如果传输层正应用着 TCP，则 TCP 将通过让源以初始数据来重传数据。因为 IP 层没有超时重传机制，所以会重传整个数据报，而不是某个片

二十四、IPv4 编址

1、IP 地址

一台主机通常只有一条链路连贯到网络，当主机上的 IP 想发送一条数据报时，就在该链路上发送。主机与物理链路之间的边界叫做 接口（interface）。

而路由器的工作是从链路上接收数据报并从某些其余链路转发进来，路由器必须有两条或更多链路与其连贯，路由器与它的任意一条链路之间的边界也叫做接口。即一台路由器会有多个接口，每个接口有其链路。

因为每台主机与路由器都能发送和接管 IP 数据报，IP 要求每台主机和路由器接口都有本人的 IP 地址。因而，一个 IP 地址技术上是与一个接口相关联的，而不是与包含该接口的主机或路由器相关联的。

2、子网

每个 IP 地址（IPv4）长度为 32 比特（4 字节），按 点分十进制记法 书写，即地址中的每个字节都用它的十进制模式书写，各字节间以点. 隔开，比方 193.32.122.30

在因特网上的每台主机和路由器上的每个接口，必须有一个寰球惟一的 IP 地址（NAT 后的接口除外）。这些地址不能自由选择，一个接口的 IP 地址的一部分须要由其连贯的子网来决定。

如图，一台路由器有三个接口，连贯 7 台主机。左侧的三台主机以及连贯它们的路由器的接口，都有一个形如 223.1.1.x 的 IP 地址。即在它们的 IP 地址中，最左侧的 24 比特是雷同的。

互联左侧这三个主机接口与 1 个路由器接口的网络造成 1 个 子网（subnet）（也被称为 IP 网络或间接称为网络）。IP 编址为这个子网调配一个地址：223.1.1.0/24，其中的 /24 记法，有时称为 子网掩码（network mask），批示了 32 比特中的最左侧 24 比特定义了子网地址。任何连贯到该子网的主机都要求其地址具备 223.1.1.x 的模式。同样图中下侧和右侧也是子网，别离为 223.1.3.0/24 和 223.1.2.0/24

上图显示了 3 台通过点对点链路彼此互联的路由器，这里呈现了 6 个子网。

一个具备多个以太网段和点对点链路的组织将具备多个子网，在给定子网上的所有设施都具备雷同的子网地址。

尽管在实践上来说，不同子网能够有齐全不同的子网地址。但上图能够看出，这 6 个子网在前 16 个比特是统一的，都是 223.1

3、无类别域间路由抉择（CIDR）

因特网的地址调配策略被称为 无类别域间路由抉择（CIDR）(也被称为无分类编址，以辨别于分类编址)。对于子网寻址，32 比特的 IP 地址被分为两局部，也是点分十进制数模式 a.b.c.d/x，其中 x 批示了地址的第一局部中的比特数，又被称为该地址的 前缀（prefix）。

一个组织通常被调配一块间断的地址，即具备雷同前缀的地址。在该组织外的的路由器仅思考后面的前缀比特 x，这相当大地缩小了在这些路由器直达发表的长度，模式为 a.b.c.d/x 繁多表项足以将数据报转发到该组织内的任何目的地。

如图，200.23.16.0/20 下有 8 个组织，别离是 200.23.16.0/23 到 200.23.30.0/23，每个组织有本人的子网。而外界不须要晓得这 8 个组织。这种应用单个网络前缀通告多个网络的能力通常称为 地址聚合 ，也称为 路由聚合 或路由摘要

4、分类编址

在 CIDR 被采纳之前，IP 地址的网络局部被限度长度为 8、16、24 比特，也就是 分类编址（classful addressing）。

具备 8、16、24 比特子网地址的子网被称为 A、B 和 C 类网络。

一个 C 类（/24）子网既能包容 2 的 8 次方 – 2 = 254 台主机（其中两个地址预留用于非凡用处），这对于很多组织来说都太小了。

而一个 B 类（/16）子网可反对多达 2 的 16 次方 – 2 = 65534

台主机，又太大了。

在分类编址办法下，一个有 2000 台主机的组织通常被分给一个 B 类（/16）地址，那么剩下的 6 万多个地址就节约掉了。这就会导致 B 类地址空间的迅速损耗以及所调配的地址空间的利用率低。

此外，255.255.255.255 是 IP 播送地址，当一台主机收回一个目标地址为该地址的数据报时，该报文会交付给同一个网络中的所有主机。

5、获取主机地址

某组织一旦取得了一块地址，它就可为本组织内的主机与路由器逐个调配 IP 地址。系统管理员通常手工配置路由器中的 IP 地址。主机地址也能手动配置，但更多应用的是 动静主机配置协定（DHCP）。DHCP 容许主机主动获取 IP 地址。网络管理员能够配置 DHCP，以使某给定主机每次与网络连接时能失去一个雷同的 IP 地址，或者某主机将被调配一个 长期的 IP 地址，该地址在每次与网络连接时兴许是不同的。

6、网络地址转换

每个 IP 地址（IPv4）长度为 32 比特（4 字节），因而总共有 2 个可能的 IP 地址，约为 40 亿个。在互联网越来越遍及的当下，集体计算机及智能手机等越来越多，这些 IP 地址显然无奈满足人们的需要。

为了解决 IP 地址有余的问题，于是就有了 网络地址转换(Network Address Translation，NAT)，它的思维就是给一个局域网络调配一个 IP 地址就够了，对于这个网络内的主机，则调配公有地址，这些公有地址对外是不可见的，他们对外的通信都要借助那个惟一调配的 IP 地址。

如果从广域网达到 NAT 路由器的所有数据报都有雷同的目标 IP 地址，那么该路由器如何晓得是发送给哪个外部主机的呢？其原理就是应用在 NAT 路由器上的一张 NAT 转换表，并在该表内蕴含了端口号及其 IP 地址。

* 假如一台主机向广域网申请数据，NAT 路由器收到该数据报，会为该数据报生成一个新的端口号替换掉源端口号，并将源 IP 替换为其广域网一侧接口的 IP 地址。当生成一个新的源端口号时，该端口号能够是任意一个以后未在 NAT 转换表中的源端口号（端口号字段是 16 比特，意味着 NAT 协定能够反对超过 60000 个并行应用路由器广域网一侧 IP 地址的连贯），路由器中的 NAT 也在其 NAT 转换表中减少一表项。

* 该 NAT 路由器收到广域网返回的数据时，路由器应用目标 IP 地址与目标端口号从 NAT 转换表中检索出该主机应用的 IP 地址和目标端口号，改写该数据报的目标 IP 地址和目标端口号，并向该主机转发该数据报

NAT 尽管在近几年失去了很宽泛的利用，但也被很多人拥护。

次要是：

* 1、端口号是用来过程编址的，而不是主机编址的（NAT 协定相似 NAT 路由器将该家庭网络的主机都当做过程解决，并通过 NAT 转换表为其调配端口号）

* 2、路由器通常仅该当解决高达第三层的分组

* 3、违反端到端准则，即主机彼此之间该当互相直接对话，结点不该当染指批改 IP 地址与端口号。

* 4、该当用 IPv6 来解决 IP 地址短缺问题

但不论拥护与否，NAT 究竟已成为当今因特网的一个重要组件

二十五、IPv6 数据报格局

1、IPv6 数据报格局

* 版本（4 比特）

该字段用于标识 IP 版本号，IPv6 将该字段值设为 6。而如果将该字段设为 4 并不能创立一个非法的 IPv4 数据报

* 流量类型（8 比特）

相似于 IPv4 数据报中的服务类型（TOS）

* 流标签（20 比特）

流标签字段是 IPv6 数据报中新增的一个字段，用来标识一条数据报的流类型，以便在网络层辨别不同的报文。

* 有效载荷长度（16 比特）

IPv6 数据报中在 40 定长字节数据报首部后的字节数量，即除了 IPv6 的数据报首部以外的其余局部的总长度

* 下一个首部（8 比特）

当 IPv6 没有扩大报头时，该字段的作用和 IPv4 的协定字段一样。当含有扩大报头时，该字段的值即为第一个扩大报头的类型

* 跳限度（8 比特）

与 IPv4 报文中的 TTL 字段相似，转发数据报的每台路由器将对该字段的内容减 1. 如果跳限度计数达到 0，则该数据报将被抛弃

* 源地址和目标地址（各 128 比特）记录源 IP 地址，目标 IP 地址

* 数据

* 下一个首部（8 比特）

当 IPv6 没有扩大报头时，该字段的作用和 IPv4 的协定字段一样。当含有扩大报头时，该字段的值即为第一个扩大报头的类型

* 跳限度（8 比特）

与 IPv4 报文中的 TTL 字段相似，转发数据报的每台路由器将对该字段的内容减 1. 如果跳限度计数达到 0，则该数据报将被抛弃

* 源地址和目标地址（各 128 比特）记录源 IP 地址，目标 IP 地址

* 数据

能够看出，在 IPv4 数据报中呈现的几个字段在 IPv6 数据报中已不复存在：

* 分片 / 从新组装

IPv6 不容许在两头路由器上进行分片和从新组装。这种操作只能在源与目的地上执行。如果路由器收到的 IPv6 数据报因太大不能转收回链路上的话，路由器会丢掉该数据报，并回一个“分组太大”的 ICMP 过错报文

* 首部测验和

因为运输层和数据链路层协定执行了测验操作，该项性能在网络层就没有必要了，从而更疾速解决 IP 分组

* 选项

选项字段不再是规范 IP 首部的一部分了。但并没有隐没，而是可能呈现在 IPv6 首部中由“下一个首部”指出的地位上。即就像 TCP 或 UDP 协定首部可能是 IP 分组中的“下一个首部”，选项字段也能是“下一个首部”

IPv6 绝对 IPv4 最重要的变动如下：

* 扩充的地址容量

IPv6 将 IP 地址长度由 32 比特减少到 128 比特，这使得实践可存在的 IP 地址减少到 2 个，约 340 万亿亿亿亿个，这是一个十分大的数字，确保全世界再也不会用尽 IP 地址，甚至能够为地球上每一粒沙子都调配一个惟一的 IP 地址

除了单播和多播地址外，IPv6 没有播送这一说法，而是引入了一种称为 任播地址 的新型地址，这种地址能够使数据报交付给一组主机中的任意一个

* 简化高效的 40 字节首部

除去共 32 字节的源地址和指标地址外，首部其余字段只占了 8 字节

* 流标签与优先级

给属于非凡流的分组打上标签，这些非凡流是发送方要求进行非凡解决的流，如一种非默认服务质量或须要实时服务的流

2、IPv6 书写和表达方式

表述和书写时，把长度为 128 比特的 IPv6 地址分成 8 个 16 位的二进制段、每一个 16 位的二进制段用 4 位的 16 进制数示意，段间用“：”（冒号）隔开（其书写办法和 IPv4 的十进制数加“.”不同）。

例如：1000:0000:0000:0000:000A:000B:000C:000D 就是每一个 16 位的二进制数的段用 4 位 16

进制数的段来示意、段间用“：”（冒号）隔开的一个 IPv6 地址；其中：各个 4 位 16 进制数的段中的高位 0

容许省略；因而，下面的 IPv6 地址也能够缩写成：1000:0:0:0:A:B:C:D。

为了更进一步简化，IPv6 的地址标准中还规定，能够在一个 IPv6 地址中 最多应用一次双冒号（::）来取代 IPv6 地址中严密相连的多个全 0 的 16 进制数的段（因为如果容许在一个 IPv6 地址中应用一次以上的双冒号时将无奈判断 IPv6 地址的长度，所以 IPv6 的地址标准中才规定：在一个 IPv6 地址中最多只能应用一次双冒号），这样下面的 IPv6 地址还能够缩写成：1000::A:B:C:D。

双冒号应用的地点能够在 IPv6 地址的后面、前面或者是两头；例如：对于 1000:0:0:0:A:B:0:0 这样的一个 IPv6 地址，能够写成 1000::A:B:0:0，也能够写成 1000:0:0:0:A:B::；然而不能写成 1000::A:B::。

带有端口号的 IPV6 地址字符串模式，地址局部该当用“[]”括起来，在前面跟着‘：’带上端口号，如 [A01F::0]:8000

二十六、从 IPv4 到 IPv6 的迁徙

基于 IPv4 的公共因特网如何迁徙到 IPv6 呢？这是个十分事实的问题

尽管 IPv6 使能零碎可做成向后兼容，即能接管、发送和路由 IPv4 数据报，但已部署的 IPv4 使能零碎却不能解决 IPv6 数据报

1、双协定栈

引入 IPv6 使能结点的最间接形式是 双栈 办法，即应用该办法的 IPv6 结点还有残缺的 IPv4 实现，即 IPv6/IPv4 结点，具备接管和发送 IPv4 和 IPv6 两种数据报的能力。

当与 IPv4 结点互操作时，IPv6/IPv4 结点可应用 IPv4 数据报；当与 IPv6 结点互操作时，IPv6/IPv4 结点又可应用 IPv6 数据报。

IPv6/IPv4 结点必须有 IPv6 与 IPv4 两种地址。此外，它们还必须能确定另一个结点是否是 IPv6 使能的或

仅 IPv4 使能的。

能够应用 DNS 来解决，若要解析的结点名字是 IPv6 使能的，则 DNS 会返回一个 IPv6 地址，否则返回一个 IPv4 地址。如果收回 DNS 申请的结点是仅 IPv4 使能的，则只返回一个 IPv4 地址。

两个 IPv6 使能的结点不应互相发送 IPv4 数据报，而如果发送方或接管方任意一个仅为 IPv4 使能的, 则必须应用 IPv4 数据报。

这样就会有上面这种状况：

如图，如果结点 A、B、E、F 都是 IPv6 使能的结点，而结点 C 和 D 是仅 IPv4 使能的结点，那么当按 A->B->C->D->E->F 程序发送数据报时,AB 之间会发 IPv6 数据报，BC 会发 IPV4 数据报，因为 IPv6 数据报特定的字段在 IPv4 数据报中无对应的局部，这些字段将会失落。因而，即便 E 和 F 之间能发 IPv6 数据报，从 D 达到 E 的 IPv4 数据报并未含有从 A 收回的初始 IPv6 数据报中的所有字段。

2、隧道

建隧道 是另一种双栈办法，该办法能解决上述问题。

假设两个 IPv6 结点要应用 IPv6 数据报进行交互，然而它们是经由两头 IPv4 路由器互联的。将两台 IPv6 路由器两头的 IPv4 路由器的汇合成为一个隧道，如 B->C->D->E。

如图，借助于隧道，在隧道发送端的 IPv6 结点可将整个 IPv6 数据报放到一个 IPv4 数据报的数据字段中。于是，该 IPv4 数据报的地址设为指向隧道接收端的 IPv6 结点，再发送给隧道中的第一个结点。而隧道中的 IPv4 路由器在它们之间为该数据报提供路由，就像看待其余 IPv4 数据报一样，齐全不晓得该数据报本身就含有一个残缺的 IPv6 数据报。而隧道接收端的 IPv6 结点最终收到该 IPv4 数据报，并确定该 IPv4 数据报中含有一个 IPv6 数据报，于是提取出该 IPv6 数据报，而后再为该 IPv6 数据报提供路由

3、NAT-PT

除了双栈和隧道计划外，还有一种 NAT-PT(Network Address Translator – Protocol Translator)附带协定转换器的网络地址转换器 计划