一、概述

（1）常用概念

• 处理时延：用于检查分组的头部信息决定将这个分组转发到何处所耗费的时间。
• 排队时延：分组在链路上等待传输的时间。
• 传输时延、存储转发时延：分组长度/链路速率，表示将分组推送到链路上所需要的时延。
• 传播时延：两个路由器之间的数据传输的耗时，距离/传播速度。
• 流量强度：分组到达队列的平均速度 * 分组长度 / 传播速度，设计系统时流量强度不应该超过1。
• 丢包：在实际应用中，流量强度大于也不会导致排队时延增加，因为路由器的设计是由成本决定的，路由器存储空间占满以后会发送丢包。
• 瞬时吞吐量：主机接受该文件的速率。吞吐量不经取决于链路的传输速率，也取决于干扰流量。
• 协议栈：各层所有协议的集合。
• 各层数据的名称：应用层=报文，运输层=报文段，网络层=数据报/数据段，链路层=数据帧，物理层=比特。
• MAC地址：链路层地址，长度为6字节（48位），用于唯一标识网络适配器（网卡）。MAC地址是一个局域网有效的地址。因此MAC地址只要经过网关等就会发生改变，因为已经换了局域网。

（2）广播信道和点对点信道

（2.1） 广播信道

• 广播信道主要有两种控制方法进行协调，一个是使用信道复用技术，一是使用 CSMA/CD 协议。
• CSMA/CD协议（表示载波监听多点接入 / 碰撞检测）：
  • 多点接入 ：说明这是总线型网络，许多主机以多点的方式连接到总线上。
  • 载波监听 ：每个主机都必须不停地监听信道。在发送前，如果监听到信道正在使用，就必须等待。
  • 碰撞检测 ：在发送中，如果监听到信道已有其它主机正在发送数据，就表示发生了碰撞。虽然每个主机在发送数据之前都已经监听到信道为空闲，但是由于电磁波的传播时延的存在，还是有可能会发生碰撞。

（2.2）点对点信道

因为不会发生碰撞，因此也比较简单，使用 PPP 协议进行控制。

• PPP协议：互联网用户通常需要连接到某个 ISP 之后才能接入到互联网，PPP 协议是用户计算机和 ISP 进行通信时所使用的数据链路层协议。

（3）NAT

• NAT的三种模式：
  • SNAT：是指在数据包从网卡发出去的数据的时候，把数据包中的源地址部分替换为指定的IP地址，这样对方就认为数据包的来源是被替换的那个IP的主机。
  • DNAT：是指数据包从网卡发送出去的时候，修改数据包中的目的IP，表现为如果你想访问A，可是因为网关NAT做了DNAT，把所有访问A的数据包更换为B的IP。
  • masqueread：是用发送数据的网卡上的IP替换源IP，因此对于那些IP不固定的场合，比如拨号网络或者通过DHCP分配的情况下就可以使用该方式。
• NAT三种模式的区别：路由是按照目的IP来选择的，因此DNAT是在pre-routing链上进行的，而SNAT是数据包发送出去的时候才进行的，因此是post-routing链上进行的。
• 转发网关与NAT网关的区别：两者主要的区别在于IP地址是否改变。不改变IP地址的网关，我们称为转发网关；改变IP地址的网关，我们称为NAT网关。

二、应用层

（1）FTP协议

• FTP是基于TCP的，FTP使用20端口作为控制端口，使用21端口作为数据端口，因此控制信息是带外的。

（1.1）主动模式（PORT）

• 原理：FTP客户端随机打开一个大于1024的端口N，向服务器21端口发送连接请求，发送FTP用户名和密码，然后打开N+1端口监听，并向服务器发送PORT N+1命令，服务器接收到指令以后会使用数据端口20连接客户端的N+1端口进行数据传输。

（1.2）被动模式（PASV）

• 原理：FTP客户端打开两个任意的本地端口N（大于1024）和N+1。第一个端口连接服务器的21端口，提交PASV命令。然后，服务器会开启一个任意的端口P（大于1024），返回“227 entering passive mode”消息，里面有FTP服务器开放的用来进行数据传输的端口。客户端收到消息取得端口号之后，会通过N+1号端口连接服务器的端口P，然后在两个端口之间进行数据传输。

（2）DNS协议

（2.1）传统DNS

• DNS协议使用53端口，基于UDP协议，MX记录允许企业将自己的域名作为邮件服务器域名。
• DNS服务器分类：根DNS服务器，全球逻辑上有13个，标号为A~M。TLD顶级域DNS服务器，负责顶级域名和所有国家的解析。权威DNS服务器，公共DNS服务器，本地DNS服务器。
• DNS记录：由Name,Value,Type,TTL构成的四元组。
  • A记录，type=A，name=主机名，value=主机IP
  • NS记录，type=NS，name=主机域，value=权威DNS地址
  • CNAME记录，type=CNAME，name=别名，value=主机名
  • MX记录，type=MX，name=邮件服务地址，value=Web服务地址
• 传统的DNS存在哪些问题？
  • 域名缓存：运营商缓存和本地缓存
  • 域名转发：某些运营商偷懒将DNS转发到其他运营商，其他运营商返回的是自己网络内部的IP，导致网速慢
  • 出口NAT：会使得运营商误判
  • 域名更新：权威DNS更新后其他DNS更新漫长，《虎牙在全球 DNS 秒级生效上的实践》
  • 解析延迟
• 对于复杂的应用，尤其是跨地域跨运营商的大型应用，则需要更加复杂的全局负载均衡机制，因而需要专门的设备或者服务器来做这件事情，这就是全局负载均衡器（GSLB，Global Server Load Balance），一般是通过配置CNAME的方式，然后告诉本地DNS服务器，让它请求GSLB解析这个域名，GSLB就可以在解析这个域名的过程中，通过自己的策略实现负载均衡。

（2.2）HTTP DNS

• 不走传统的DNS解析，而是自己搭建基于HTTP协议的DNS服务器集群，分布在多个地点和多个运营商。当客户端需要DNS解析的时候，直接通过HTTP协议进行请求这个服务器集群，得到就近的地址。使用HTTP DNS的，往往是手机应用，需要在手机端嵌入支持HTTP DNS的客户端SDK。
• 参照阿里云CDN HTTP DNS方式，参数是客户端IP地址和待解析的域名；然后返回多个IP地址，客户端轮询多个IP地址。
• CDN的两种工作方式
  • 边缘计算模式：定时从源数据那里同步存储的数据，然后在边缘进行计算得到结果。
  • 路径优化模式：源站点生成数据分发，根据地理位置寻找最近分发点。

(3)HTTP、HTTPS、QUIC协议

（3.1）HTTP与邮箱协议

• SMTP客户端运行在25端口，建立与SMTP服务端的连接。
• HTTP是拉协议，也是非持久连接，SMTP是推协议，是持久连接。SMTP要求报文的格式都使用7位ACSII码。发送邮件是推送，接收邮件是拉取，可以借助IMAP（端口：143）、POP3（端口：110）、HTTP（端口：80）完成。
• SMTP 只能发送 ASCII 码，而互联网邮件扩充 MIME 可以发送二进制文件。MIME 并没有改动或者取代 SMTP，而是增加邮件主体的结构，定义了非 ASCII 码的编码规则。
• POP3 的特点是只要用户从服务器上读取了邮件，就把该邮件删除。但最新版本的 POP3 可以不删除邮件。
• IMAP 协议中客户端和服务器上的邮件保持同步，如果不删除邮件，那么服务器上的邮件也不会被删除。IMAP 这种做法可以让用户随时随地去访问服务器上的邮件。

（3.2）HTTP 状态码

• 1xx 信息
  • 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
• 2xx 成功
  • 200 OK
  • 204 No Content：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
  • 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。
• 3xx 重定向
  • 301 Moved Permanently ：永久性重定向
  • 302 Found ：临时性重定向
  • 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
  • 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
  • 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。
• 4xx 客户端错误
  • 400 Bad Request ：请求报文中存在语法错误。
  • 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
  • 403 Forbidden ：请求被拒绝。
  • 404 Not Found
• 5xx 服务端错误
  • 500 Internal Server Error ：服务器正在执行请求时发生错误。
  • 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

（3.3）HTTP1.1和2.0的区别

• HTTP的报文大概分为三大部分。第一部分是请求行（方法+URL+版本），第二部分是请求的首部（键值对），第三部分才是请求的正文实体。HTTP协议是基于TCP协议的，所以它使用面向连接的方式发送请求，通过Stream二进制流的方式传给对方。当然，到了TCP层，它会把二进制流变成一个的报文段发送给服务器。
• HTTP 1.1在应用层以纯文本的形式进行通信。每次通信都要带完整的HTTP头，而且不考虑pipeline模式的话，每次的过程总是像上面描述的那样一去一回。这样在实时性、并发性上都存在问题。
• 为了解决这些问题，HTTP 2.0会对HTTP的头进行一定的压缩，将原来每次都要携带的大量key value在两端建立一个索引表，对相同的头只发送索引表中的索引。
• 另外，HTTP 2.0协议将一个TCP的连接中，切分成多个流，每个流都有自己的ID，而且流可以是客户端发往服务端，也可以是服务端发往客户端。它其实只是一个虚拟的通道。流是有优先级的。
• HTTP 2.0还将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码。常见的帧有Header帧，用于传输Header内容，并且会开启一个新的流。再就是Data帧，用来传输正文实体。多个Data帧属于同一个流。
• HTTP 2.0成功解决了部分HTTP 1.1的队首阻塞问题，同时，也不需要通过HTTP 1.x的pipeline机制用多条TCP连接来实现并行请求与响应；减少了TCP连接数对服务器性能的影响，同时将页面的多个数据css、js、 jpg等合并，通过一个数据链接进行传输，能够加快页面组件的传输速度。
• HTTP 2.0虽然大大增加了并发性，但还是有问题的。因为HTTP 2.0也是基于TCP协议的，TCP协议在处理包时是有严格顺序的。当其中一个数据包遇到问题，TCP连接需要等待这个包完成重传之后才能继续进行。虽然HTTP 2.0通过多个stream，使得逻辑上一个TCP连接上的并行内容，进行多路数据的传输，然而这中间并没有关联的数据。一前一后，前面stream 2的帧没有收到，后面stream 1的帧也会因此阻塞。于是，就又到了从TCP切换到UDP，这就是Google的QUIC协议。

（3.4）HTTP1.1的缺陷

• 高延迟，带来页面加载速度降低，网络延迟的主要问题主要是由于队头阻塞，导致带宽无法被充分利用
  • 将同一个页面的资源分散到不同的域名下，提升连接上限。因为Chrome有个机制就是对于同一个域名，默认允许同时建立6个TCP持久连接，使用持久连接可以公用一个TCP管道，但是在一个管道内只可以同时处理一个请求。
  • Spriting合并多个小图片为一个大图，再从浏览器端使用JavaScript或者CSS将图片分割。
  • 将图片使用Base64编码，内联到CSS中，减少网络请求次数。
  • 将多个较小的JavaScript使用WebPack等打包工具合并为一个大体积的JavaScript文件。
• 无状态，带来巨大的HTTP头部信息
• 明文传输，不安全
• 不支持服务器推送消息

（3.5）SPDY与HTTP2.0

• SPDY：与2009年，Google公开了自行研发的SPDY协议，主要解决HTTP效率不高问题。2015年，HTTP2基于SPDY协议发布，专注于性能。
• HTTP2新特性
  • 二进制传输，将请求相应数据分割为更小的数据帧，并采用二进制编码。
  • Header压缩，专门开发了HPACK压缩算法，在客户端和服务器端建立字典（索引表），用索引表示重复字符串，采用哈夫曼编码来压缩整数和字符串。
  • 多路复用，不再依赖TCP连接去实现并行多流。同一个域名下的通信都在单个连接完成，单个连接可以双向传输数据，数据流以消息的形式发送，每个请求都可以携带31Bit的数据。
  • 服务端推送，在浏览器下载HTML的时候，服务端预测将可能用到的数据提前下载，比如JS文件或者CSS文件。
  • 提高了安全性，不强制加密，但是事实上都是加密的数据，HTTP2定义了两个字符串表示，h2表示加密的，h2c表示明文的。
• HTTP2.0缺陷
  • TCP的TLS连接建立耗时
  • TCP队头阻塞问题没有完全解决
• HTTP3新特性
  • Google意识到SPDY的问题后又推出了QUIC协议。HTTP3基于QUIC协议。

（3.6）QUIC协议

• 自定义连接机制：一条TCP连接是由四元组标识的，分别是源 IP、源端口、目的 IP、目的端口。一旦一个元素发生变化时，就需要断开重连，重新连接。在移动互联情况下，当手机信号不稳定或者在WIFI和 移动网络切换时，都会导致重连，从而进行再次的三次握手，导致一定的时延。这在TCP是没有办法的，但是基于UDP，就可以在QUIC自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个64位的随机数作为ID来标识，而且UDP是无连接的，所以当IP或者端口变化的时候，只要ID不变，就不需要重新建立连接。
• 自定义重传机制：TCP为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题。任何一个序号的包发过去，都要在一定的时间内得到应答，否则一旦超时，就会重发这个序号的包。这个超时是通过采样往返时间RTT不断调整的。其实，在TCP里面超时的采样存在不准确的问题。例如，发送一个包，序号为100，发现没有返回，于是再发送一个100，过一阵返回一个ACK101。这个时候客户端知道这个包肯定收到了，但是往返时间是多少呢？是ACK到达的时间减去后一个100发送的时间，还是减去前一个100发送的时间呢？事实是，第一种算法把时间算短了，第二种算法把时间算长了。QUIC也有个序列号，是递增的。任何一个序列号的包只发送一次，下次就要加1了。例如，发送一个包，序号是100，发现没有返回；再次发送的时候，序号就是101了；如果返回的ACK 100，就是对第一个包的响应。如果返回ACK 101就是对第二个包的响应，RTT计算相对准确。但是这里有一个问题，就是怎么知道包100和包101发送的是同样的内容呢？QUIC定义了一个offset概念。QUIC既然是面向连接的（所谓的连接其实是两边的状态，状态如果不在udp层维护，就可以在应用层维护），也就像TCP一样，是一个数据流，发送的数据在这个数据流里面有个偏移量offset，可以通过offset查看数据发送到了哪里，这样只要这个offset的包没有来，就要重发；如果来了，按照offset拼接，还是能够拼成一个流。
• 无阻塞的多路复用：同HTTP 2.0一样，同一条QUIC连接上可以创建多个stream，来发送多个 HTTP 请求。但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。这样，假如stream2丢了一个UDP包，后面跟着stream3的一个UDP包，虽然stream2的那个包需要重传，但是stream3的包无需等待，就可以发给用户。
• 自定义流量控制：TCP的流量控制是通过滑动窗口协议。QUIC的流量控制是通过window_update，来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在一个连接中的每个stream控制窗口。

（3.7）SSL的四次握手过程

• 客户端请求建立SSL连接，发送支持的加密方式以及一个随机数client random给服务器；
• 服务器选择其中的一种加密方式，并且再加上另外一个随机数server random，和数字证书（其中有公钥），发送给客户端；
• 客户端确认这个数字证书是有效的，并且再生成一个新的随机数new client random，将这个随机数用服务器发送给它的数字证书中的公钥进行加密发送给服务器；
• 服务器收到客户端的回复，利用自己的私钥进行解密，获得这个随机数，然后通过将前面这三个随机数以及他们协商的加密方式，计算生成一个对称密钥。
• 至此握手阶段完成，之后的会话他们就通过这个非对称密钥进行加密传输。HTTPS可以完成上述HTTP的缺陷：通过对通信内容加密保证了内容的安全性。并且通过数字证书可以验证双方的身份，因为数字证书是由权威机构（CA）颁布的。并且因为报文中有发送方的数字签名，所以接收方可以先验证数字签名，从而验证了数据没有被篡改，保证了完整性。

（3.8）HTTPS的缺陷

• HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电。
• HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响。
• SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
• SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
• HTTPS协议的加密范围也比较有限，在******、拒绝服务***、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人***一样可行。

（3.9）HTTPS性能优化

• TCP性能优化：每个 TCP 连接都有一个称为拥塞窗口的速度极限，这个窗口最初时较小，在可靠性能保证的情况下随时间增长。这种机制被称为慢启动。因此，对于所有的 TCP 连接，启动速度很慢，对于 TLS 连接情况则更糟糕，因为 TLS 握手协议消耗了宝贵的初始连接字节（当拥塞窗口较小时）。如果拥塞窗口足够大，那么慢启动不会有额外的延迟。但是，如果较长的握手协议超过了拥塞窗口的大小，发送方必须将它拆分为两块，先发送一块，等待确认（一个往返），增加拥塞窗口，然后再发送剩下的部分。启动速度限制被称为 初始拥塞窗口。RFC6928 建议初始拥塞窗口设置为10个网络段（约15KB）。早期的建议是使用2-4个网络段起步。在旧版本的Linux平台上，可以改变路由的初始拥塞窗口。慢启动可以作用于一段时间内没有任何流量的连接上，降低其速度，并且速度下降地非常快。 在 Linux 上，可以在连接空闲时禁用慢启动。sysctl -w net.ipv4.tcp_slow_start_after_idle=0

• 使用长连接：大部分情况下 TLS 性能影响集中在每一个连接的开始握手阶段。一个重要的优化技术是在连接数允许的情况下尽可能保持每个连接不断开。长连接的缺点是在最后一个 HTTP 连接完成之后，服务器在关闭连接之前会等待一定时间，虽然一个连接不会消耗太多的资源，但是降低了服务器的总体伸缩性。长连接适用于客户端突发大量请求的场景。如果 TLS 是由 OpenSSL 处理的，请确保服务器正确设置SSL_MODE_RELEASE_BUFFERS标识。

• 尽可能的使用HTTP/2.0版本。

• CDN，使用 CDN 可以实现世界级的性能，它利用地理上分散的服务器提供边缘缓存和流量优化。

• 减少秘钥交换：使用 TLS 最大的成本除了延迟以外，就是用于安全参数协商的 CPU 密集型加密操作。这部分通讯称为密钥交换（key exchange）。密钥交换的 CPU 消耗很大程度上取决于服务器选择的私钥算法、私钥长度和密钥交换算法。

• 证书：一次完整的 TLS 握手期间，服务器会把它的证书链发送给客户端验证。证书链的长度和正确性对握手的性能有很大影响。

  • 使用尽可能少的证书：证书链里的每个证书都会增大握手数据包，证书链中包含太多证书有可能导致 TCP 初始拥塞窗口溢出。
  • 只包含必需的证书：证书链里包含非必需证书是个常见错误，每个这样的证书会给握手协议额外增加1-2KB。
  • 提供完整的证书链：服务器必须提供一个被根证书信任的完整证书链。
  • 使用椭圆曲线证书链：因为 ECDSA 私钥长度使用更少的位，所以 ECDSA 证书会更小。
  • 避免同一张证书绑定过多域名：每增加一个域名都会增加证书的大小，对于大量域名来说会有明显的影响。

• 吊销检查：虽然证书吊销状态在不断变化，并且用户代理对证书吊销的行为差异很大，但是作为服务器，要做的就是尽可能快地传递吊销信息。

  • 使用 OCSP：信息的证书 OCSP 被设计用于提供实时查询，允许用户代理只请求访问网站的吊销信息，查询简短而快速（一个HTTP请求）。相比之下 CRL 是一个包含大量被吊销证书的列表。
  • 使用具有快速且可靠的 OCSP 响应程序的 CA：不同 CA 之间的 OCSP 响应程序性能不同，在你向 CA 提交之前先检查他们的历史 OCSP 响应程序。 另一个选择 CA 的标准是它更新 OCSP 响应程序的速度。
  • 部署 OCSP stapling：OCSP stapling 是一种允许在 TLS 握手中包含吊销信息（整个OCSP响应）的协议功能。启用之后，通过给予用户代理进行吊销检查的全部信息以带来更好地性能，可以省去用户代理通过独立的连接获取 CA 的 OCSP 响应程序来查询吊销信息。
  • 协议兼容：如果你的服务器与一些新版本协议的特性（例如TLS 1.2）不兼容，浏览器可能需要通过与服务器进行多次尝试，才能协商一个加密的连接。确保良好的 TLS 性能的最好方式是升级最新的 TLS 协议栈以支持较新的协议版本和扩展。
  • 硬件加速：随着 CPU 速度的不断提高，基于软件的 TLS 实现在普通 CPU 上已经运行得足够快，无需专门的加密硬件就能处理大量的 HTTPS 请求。但安装加速卡或许能够提升速度。

（3.10）SSL和TLS的区别

• Secure Socket Layer，安全套接字层，SSL位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。
  • SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  • SLL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
  • Transport Layer Security，传输层安全协议，用于两个应用程序之间提供保密性和数据完整性。
  • SSL是Netscape开发的专门用于保护Web通讯的，目前版本为3.0.最新版本的TLS 1.0是IETE（工程任务组）指定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。
  • 安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两成组成：TLS记录协议（TLS Record）和TLS握手协议（TLS Handshake）。
  • TLS的最大优势就在于：TLS是独立于应用的协议。高层协议可以透明地分布在TLS协议上面。然而，TLS标准并没有规定应用程序如何在TLS上增加安全性；它如何启动TLS握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。

（3.11）HTTPS 11次握手流程图

(3.12) HTTP与Restful

• HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。
• 所有的安全方法也都是幂等的。POST方法为什么不是幂等的？POST所对应的URI并非创建的资源本身，而是资源的接收者。比如：POST http://www.forum.com/articles 的语义是在 http://www.forum.com/articles 下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性。
• HTTP协议本身是一种面向资源的应用层协议，但对HTTP协议的使用实际上存在着两种不同的方式：一种是RESTful的，它把HTTP当成应用层协议，比较忠实地遵守了HTTP协议的各种规定；另一种是SOA的，它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立了自己的应用层协议。
• 在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。在使用 XMLHttpRequest 的 POST 方法时，浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做，例如火狐就不会。但是GET 方法 Header 和 Data 会一起发送。
• HTTPS并非是应用层的一种新协议，它只是在HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。
• 浏览器使用HTTP时，直接同TCP通信；当浏览器使用HTTPS时，浏览器会先同TLS/SSL进行通信，然后TLS/SSL再同TCP进行通信。在使用TLS/SSL后，HTTP便拥有了加密功能。TLS/SSL是独立于HTTP的协议，所以其也可以同应用层的其他协议配合使用。SSL类似于TCP的三次握手，在HTTP链接建立之前进行四次握手，从而客户度和服务端沟通好HTTP传输时对称加密的密钥。

三、运输层

（1）概述

• 运输层协议是为运行在不同主机上的进程提供逻辑通信，而网络层协议是为主机提供逻辑通信。
• TCP协议的信息分组叫做数据段，而UDP协议的信息分组叫做数据报。
• 进程可能有多个套接字，每个套接字都有一个唯一的标识符，其格式取决于是TCP套接字还是UDP套接字。
• UDP的套接字使用(目的地址,目的端口)描述，TCP的套接字使用(源地址,源端口,目的地址,目的端口)。
• UDP发送报文是并没有双方握手，因此UDP是面向无连接的。
• UDP使得应用层可以更好的控制数据发送的时间和要发送的数据。
• RIP的选路表就是使用的UDP。UDP的首部只有4个字段，每个字段2字节。

（2）TCP可靠数据传输原理

TCP是在端到端不可靠的网络层IP上实现的可靠传输。

• （1）仅考虑单向数据传输的情况 下，先认为底层信道是完全可靠的。接受端和发送端等待上下层的函数调用发送接收数据即可。但是更为现实的就是底层信道模型分组中的比特更有可能受损。因此需要构建一条具有比特差错检测的可靠数据传输类似于我们的电话讲话，这种口述消息传递使用了肯定确认和否认机制。

• （2）在计算机网络中，基于这样的重传机制叫做自动重传请求ARQ。ARQ协议中需要使用差错检测，接收方反馈和重传实现。那么在发送端不仅仅需要等待上层的调用了，还需要在调用后等待ACK和NAK。但是这样一来，ACK和NAK的分组受损后还是无法实现接收方反馈，因此，可以通过冗余分组实现，给分组贴上序号，便可知道该次回应是否是针对该次数据传送。贴上序号后需要等待ACK是否是0或者1。为了实现基于时间的重传机制，那么需要一个重传倒计数定时器。在每次发送一个分组以后便启动一个定时器。当收到来自接收端的ACK=1之后便终止定时器。但是该协议的一个问题是性能，那就是停等。

• （3）解决该问题就要实现流水线技术，不使用停等的方式，允许发送放发送分组无需等待确认。但是带来的问题就是必须增加序号范围，因为每一个分组都需要一个唯一标识。还有就是协议的发送方和接收方必须实现缓存多个分组。所需要的序号范围和分组缓冲大小取决于数据传输协议响应丢失，差错和过度延时分组的方式。解决流水线技术带来的差错恢复问题有两种方案: 回退N步(GBN)和选择重传(SR)。GBN协议核心就是在那些已经传输但是还未被确认的分组的许可序号范围可以看做是一个长度为N的窗口，因此，该协议也叫作滑动窗口协议。

• （4）然而，GBN协议也存在性能问题，就是窗口长度和带宽时延积都很大的时候，流水线中会有很多分组。一个分组的差错就有可能导致GBN重传大量的分组。因此选择重传可以让发送方重传那些可能出错的分组。这种个别的，按需的重传要求接收方逐个确认正确的分组。再用窗口长度N来限制流水线中未被确认的分组数。SR的接收方将确认一个正确的分组不管是否有序，失序的分组将被缓存起来，直到所有丢失的分组全都收到才向上层交付。

• （5）TCP协议是面向连接的，传输的双方必须先握手，完成一直保持连接状态，但是这种连接是松散的。TCP协议也是一种全双工的，并且是点对点的。

• （6）一旦建立一个TCP连接，那么将这些数据引导至发送缓存，发送缓存时在三次握手之后建立的缓存。接下来TCP将会不断地在缓存中取出数据。从缓存中取出数据的多少取决于最大报文段长MSS。该MSS通常由最初决定的最大链路层帧长度所设置，本地主机发送长度是这样的帧，也就是最大传输单元MTU。TCP将每块数据添加一个TCP头，从而形成多个TCP段。

• TCP给应用程序提供了流量控制服务，以消除发送方使接收缓存溢出的可能性。因此可以说流量控制服务是一个速度匹配服务。TCP发送方也可能因为IP网络的拥塞被遏制，这种形式的发送方的控制被称为拥塞控制。

• TCP通过让发送方保留一个接收窗口的变量来提供流量控制。

  （3）TCP建立和断开连接的过程及状态变化

（3.1）连接过程

• （1）客户端的TCP首先向服务器端发送一个不包含应用层数据的特殊报文段，在报文段的首部中的一个标志位SYN=1。另外客户端会随机选择一个起始序号，并将这个编号放置在TCP SYN的序号字段中。
• （2）到达服务器后将会取出TCP SYN的字段序号，为这个TCP连接分配TCP缓存和变量，并向客户端发送允许连接的字段。服务端向客户端回复的报文也会将SYN=1，TCP SYN头部的确认字段被置为随机客户端序号+1，最后服务端也会创建一个随机的序号放到TCP头部。这个报文段被称作SYNACK报文段。
• （3）一旦收到SYNACK报文段，客户端也会分配缓存和变量。客户端读取服务端的随机序号+1再放到TCP头部，确认连接。再次发送含有应用层数据的报文SYN=0。
• （4）当客户端想要断开连接的时候首先会发送一个特殊报文段，FIN=1，然后服务端会发送ACK=1的报文段确认收到。然后服务端再发送SYN=1的报文段，客户端也会响应ACK=1。

（3.2）状态变化

• 客户端状态：首先发送SYN，客户端进入SYN_SEND状态，服务器接受SYN，并发送SYNACK后双方进入ESTABLISHED状态，表示连接已经建立。当客户端应用程序想要断开的时候发送FIN并进入FIN_WAIT_1状态，等待服务端回复ACK，接收到后进入FIN_WAIT_2状态。然后服务端发送FIN，客户端接收到后进入TIME_WAIT状态，并发送ACK确认报文。随后进入CLOSED状态。
• 服务端状态：首先启动服务器端程序以后，将进入LISTEN状态，接收到SYN并发送SYNACK后进入SYN_RECV状态，接收到客户端发来的ACK后将进入ESTABLISHED状态。当接收到客户端的FIN后立即发送ACK并使自己进入CLOSE_WAIT状态。然后发送FIN，进入LAST_FIN状态，当收到客户端的ACK后进入CLOSED状态。

对于TIME_WAIT持续两个MSL的作用?

• 可靠的关闭tcp的连接。比如网络拥塞，如果主动关闭方最后一个ACK没有被接收方收到的话，在此时因为持续了两个MSL而尚未关闭的TIME_WAIT就会把这些尾巴问题给处理掉，比如说，重新启动TIME_WAIT,然后重新发送给一次ACK。
• 防止由于没有持续TIME_WAIT的时间导致新的TCP连接建立起来，延迟的FIN重传包会干扰新的连接。

（4）TCP的拥塞控制

TCP采用的拥塞控制方法是让每一个发送方根据所感知的网络拥塞程度来限制其能向连接发送的流量速率。如果一个TCP发送方感知在该路径上没有拥塞，则TCP发送方增加其发送速率，否则就会降低发送速率。

(4.1) TCP是如何限制发送速率的？

TCP的每一端都有接收缓存，发送缓存和变量。TCP拥塞机制让连接的每一端都记录一个变量，也就是拥塞窗口。拥塞窗口限制了发送方的未确认数据量，因此简介的限制了发送速率。

(4.2) TCP发送方如何感知路径上出现拥塞？

TCP定义了一个丢失事件，出现超时或者发送方接收到三个ACK。因为TCP使用确认的方式来触发它的拥塞窗口长度的增大，所以TCP被称作是自定时的。

(4.3) TCP拥塞控制算法(以TCP Reno为例)

• 线性增加，乘性减少：当出现丢包事件的时候让发送方降低其发送速率。因为通过该相同的拥塞的路由器的其他TCP连接也很可能产生丢包事件，它们也可能会通过减少相同的窗口值来降低发送速率，因此，该整体作用是让所有通过这一个拥塞路由器的路径的路径的源主机降低向该网络发送数据的速率。TCP采用乘性减少的方式来降低发送速率，每次发生一次丢包事件都会将拥塞窗口减半。但最小不低于1个MSS。当提高发送速率的时候采用线性增加的方式，如果检测到没有丢包事件，那么TCP将会慢慢增加拥塞窗口长度，谨慎的探测可用的带宽资源。每个往返延时都会增加一个MSS。TCP拥塞控制协议的线性增长阶段称为避免拥塞。这样TCP的发送速率维持在一个锯齿状的图形中。
• 慢启动：当一个TCP连接开始的时候拥塞窗口为一个MSS，但是对于高速网络来说，速率的增长是很慢的，因此这是很遗憾的事情，所以发送方在初始阶段不是线性增加而是指数增加。因此在这个慢启动的初始化阶段期间，TCP发送方会以很慢的速率开始传输，但是会以指数方式增加传输速率。
• 对超时事件的反应：TCP对收到3个冗余ACK和超时事件的反应是不一样的，当发生超时事件，会进入慢启动过程。TCP通过维持一个阈值变量来管理这些较为复杂的动态过程。该阈值用来确定慢启动将结束并且避免拥塞将开始的窗口长度。阈值在初始化的时候被设置为一个很大的值，当发生丢包就减半，当发生超时事件后就会进入慢启动阶段，当拥塞窗口增长到阈值为止。这种收到ACK取消进入慢启动的过程叫做快速恢复。

（4.4）滑动窗口协议和拥塞窗口协议的关系

• 滑动窗口协议是传输层进行流控的一种措施。
• 拥塞窗口是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。

四、网络层

• 网络层协议IP提供主机之间的逻辑连接。其服务模型是尽力而为的交付服务。IP是不可靠的信息服务。将主机之间的交付扩展到主机进程上称为运输层的多路复用和多路分解。
• 一个链路层数据报能承载的最大数据量叫做最大传输单元MTU。
• 每个IP数据报封装在链路层数据报中，再从一台路由器运输到下一个路由器，链路层协议MTU严格限制着IP数据报长度。
• 由于不同的协议采用的MTU不同，因此IP数据报会划分成更小的片进行传输。

五、链路层

• 适配器是一个半自治的单元。

六、OSI/RM七层模型与TCP/IP四层对应关系

• 应用层：应用层，表示层，会话层
• 传输层：运输层
• 网络层：网络层
• 网络接入层：数据两路层，物理层