吴耿龙

Web开发技术分享

首页 归档 标签 关于

web工程师应该懂的计算机网络知识，TCP/IP协议

2019-03-05 30 min read # 计算机网络 # TCP/IP # UDP

OSI七层参考模型

OSI（Open System Interconnection）参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。

应、表、会、传、网、数、物

  1. 应用层： 直接和应用程序接口，为应用进程提供服务。其作用是在实现多个系统应用进程相互通信的同时，完成一系列业务处理所需的服务。（网络服务与最终用户的一个接口）如HTTP/FTP/SMTP/POP3

    协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP

  2. 表示层：在数据传输之前，对加密、解密、压缩、解压缩、格式化、代码转换、安全等提供一套约定和规则。

    格式有，JPEG、ASCll、DECOIC、加密格式等

  3. 会话层：对会话的双方进行资格审查和校验，同时规定发送时的双工模式。会话层使用校验点可使通信会话在通信失效时从校验点继续恢复通信。

  4. **传输层：**接受会话层的数据，在必要的时候把数据进行分割，并将这些数据交给网络层，在两个实体之间建立端到端可靠的通信信道，以及流控和差错校验。TCP UDP，数据包一旦离开网卡即进入网络传输层。

  5. 网络层：负责建立、保持和终止通过中间设备的连接，实现不同网络之间的路径选择、拥挤控制，为数据包选择路由。IP协议属于该层。路由器、交换机。

  6. 数据链路层：将数据组装成帧，帧是本层的传输单位，为数据在传输过程中建立逻辑连接、进行硬件地址寻址、差错校验，调节发送速率使之与接收方匹配。mac地址

  7. 物理层： 建立、维护、断开物理连接，以二进制数据形式在物理媒体上传输数据。包括设备之间物理连接的接口、用户设备与网络终端设备之间的传输规则。

Alt text

TCP/IP四层模型

  1. 应用层：

    负责处理特定的应用程序细节。包括Telnet（远程登录）、FTP（文件传输协议）、SMTP（简单邮件传送协议）以及SNMP（简单网络管理协议）等。

  2. 传输层：

    • 主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，有两种传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。

    • TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，设置发送最后确认分组的超时时钟等。

    • UDP为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。

    • 特点：

      1、由应用程序产生应用进程，由应用进程产生进程端口号，由端口号提供相应的服务。

      2、TCP发送进程以字节流的形式传递数据，而接收进程也把数据作为字节流来接收，类似于假想的管道

      3、UDP发送进程发送的数据报文都是独立的，因此UDP不是面向流的协议

      4、缓存：数据流向的每一个方向上都有两种缓存：发送缓存、接收缓存

      5、在传输层向IP层发送数据时要以分组为单位，而不是按字节流来发送，TCP协议把若干字节构成一个分组，我们可以把这样的分组称为报文段( segment)，这种报文段并不一定都一样长，可以几个字节，也可以是几千个字节

  3. 网络层：

    也称作网络互联层，处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。

  4. 数据链路层：

    也称作网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。

img

  • PDU: Protocol dateⅦnit:表示对等层之间传递的数据单位

  • TCP: Transmission control protoco1:传输控制协议

  • UDP: User Dategram Protoco1:用户数据报协议

  • IP: Internet protocol:互联网报文协议

  • ICMP: Internet Control Message Protocol:互联网控制报文协议

    ping、traceroute 差错通知、信息查询

  • ARP: Address resolution protocol:地址解析协议

    用于将计算机的网络P地址转化为物理MAC地址。ARP协议的基本功能就是通过目标设备的P地址，查询目标设备的MAC地址，以保证通信的顺利进行。在每台安装有TCP/P协议的电脑里都有个ARP缓存表，表里的P地址与MAC地址是—对应的。

  • RARP: Reverse Address resolution protocol:反向地址解析协议

    使只知道自己硬件地址的主机能够知道其IP地址，这种主机往往是无盘工作站。因此RARP协议目前已很少使用。

IP协议

IP提供不可靠的，无连接的数据传送服务。 不可靠指它不能保证IP数据报能成功到达目的地。

**不可靠：**它不能保证IP数据报能成功地到达目的地。如果发生某种错误时，如某个路由器暂时用完了缓冲区，IP有一个简单的错误处理算法：丢弃该数据报，然后发送ICMP消息报给信源端。任何要求的可靠性必须由上层来提供（如TCP）。

**无连接：**IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。这也说明，IP数据报可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报（先是A，然后是B），每个数据报都是独立地进行路由选择，可能选择不同的路线，因此B可能在A到达之前先到达。

TCP协议

特点

TCP协议的特点：

  1. 面向连接；
  2. TCP提供可靠交付的服务；
  3. 面向字节流。面向字节流的含义：虽然应用程序和TCP交互是一次一个数据块，但TCP把应用程序交下来的数据仅仅是一连串的无结构的字节流。
  4. 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的；
  5. TCP提供全双工通信。数据在两个方向上独立的进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号；

套接字（socket、插口、套接口）地址：包含 IP地址和端口

TCP的三次握手

三次握手
  1. 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
  2. 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
  3. 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入连接成功ESTABLISHED(established)状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

客户端：“喂，听得到吗？”

服务器：“听到了，你能听到我讲话吗？”

客户端：“很清楚，我们开始聊天吧。”

TCP的四次挥手

img

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

客户端：“我要断开连接了。”

服务器：“好的。”

服务器：“我也要断开连接了。”

客户端：“好的。”

简述 HTTP 协议的工作流程

  1. 地址解析;
    在浏览器中输入 URL，浏览器会从中分解出协议名、主机名、端口、对象路径等部分
  2. 封装 HTTP 请求数据包
  3. 浏览器获取主机 IP 地址，建立 TCP 链接（TCP 的三次握手）
  4. TCP 链接建立后发送 HTTP 请求
    请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和可能的内容。
  5. 服务器接到请求后，给予相应的响应信息
    其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容
  6. 服务器断开 TCP 连接

问题1：为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

问题2：为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

问题3：为什么不能用两次握手进行连接？

​ 为了实现可靠数据传输， TCP 协议的通信双方，双方都知道彼此已准备好，同时都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤。
​ 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。

问题4：如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

状态详解

​ **LISTEN：**侦听来自远方的TCP端口的连接请求

​ **SYN-SENT：**再发送连接请求后等待匹配的连接请求（客户端）

​ **SYN-RECEIVED：**再收到和发送一个连接请求后等待对方对连接请求的确认（服务器）

​ **ESTABLISHED：**代表一个打开的连接

​ **FIN-WAIT-1：**等待远程TCP连接中断请求，或先前的连接中断请求的确认

​ **FIN-WAIT-2：**从远程TCP等待连接中断请求

​ **CLOSE-WAIT：**等待从本地用户发来的连接中断请求

​ **CLOSING：**等待远程TCP对连接中断的确认

​ **LAST-ACK：**等待原来的发向远程TCP的连接中断请求的确认

​ **TIME-WAIT：**等待足够的时间以确保远程TCP接收到连接中断请求的确认

​ **CLOSED：**没有任何连接状态

UDP协议

用户数据报协议（User Datagram Protocol，UDP）UDP是OSI参考模型中一种无连接的传输层协议，它主要用于不要求分组顺序到达的传输中，分组传输顺序的检查与排序由应用层完成 ，提供面向事务的简单不可靠信息传送服务。

特点

  1. 面向事物，不是面向链接。
  2. UDP不提供可靠性：它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。简单的可以理解UDP就是类似一个邮寄员的角色。你只要告诉它，对方的地址和电话。邮递员就把你的快递送到对应的地方，但是中间可能会丢失。对方收到没有，就不管了。

UDP 是一个简单的传输层协议。和 TCP 相比，UDP 有下面几个显著特性：

  • UDP 缺乏可靠性。UDP 本身不提供确认，序列号，超时重传等机制。UDP 数据报可能在网络中被复制，被重新排序。即 UDP 不保证数据报会到达其最终目的地，也不保证各个数据报的先后顺序，也不保证每个数据报只到达一次
  • UDP 数据报是有长度的。每个 UDP 数据报都有长度，如果一个数据报正确地到达目的地，那么该数据报的长度将随数据一起传递给接收方。而 TCP 是一个字节流协议，没有任何（协议上的）记录边界。
  • UDP 是无连接的。UDP 客户和服务器之前不必存在长期的关系。UDP 发送数据报之前也不需要经过握手创建连接的过程。
  • UDP 支持多播和广播。

HTTP协议

特性

  1. HTTP构建于TCP/IP协议之上，默认端口号是80
  2. HTTP是无连接无状态的，就是每次的请求和之后的请求都是没有关系的。

组成

请求：状态行、请求头、消息主体

响应：状态行、响应头、响应正文

常见状态码

  • 100：继续 客户端应当继续发送请求。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。

  • 101： 转换协议 在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。

  • 102：继续处理 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

  • 200 OK 客户端请求成功

  • 301 Moved Permanently 请求永久重定向

  • 302 Moved Temporarily 请求临时重定向

  • 304 Not Modified 文件未修改，可以直接使用缓存的文件。

  • 400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。

  • 401 Unauthorized 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用

  • 403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因

  • 404 Not Found 请求的资源不存在，例如，输入了错误的URL

  • 500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。

  • 502 Bad Gateway 错误的网关，作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

  • 503 Service Unavailable 服务器当前不能够处理客户端的请求，这个状况是临时的，在一段时间之后，服务器可能会恢复正常。

常见请求\响应头

  • Content-Type

  • Accept

  • Origin

  • Cookie

  • Cache-Control

  • User-Agent

  • Referrer

  • X-Forwarder-For

  • Access-Control-Allow-Origin

  • Last-Modified

HTTP协议请求方法

  • GET
  • POST
  • HEAD：跟GET方法相同，只不过服务器响应时不会返回消息体。
  • OPTIONS：获取服务器支持的HTTP请求方法；用来检查服务器的性能
  • PUT
  • DELETE
  • TRACE：超文本传输协议，定义的一种协议调试方法，该方法会使服务器原样返回任意客户端请求的任何内容。

HTTP的基本优化

影响一个HTTP网络请求的因素主要有两个：带宽和延迟。

  • **带宽：**拨号上网的阶段带宽可能会成为一个比较严重影响请求的问题，但是现在影响的可能性小。
  • 延迟：
  • 浏览器阻塞（HOL blocking）：浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
  • DNS 查询（DNS Lookup）：这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
  • 建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

HTTP1.0和HTTP1.1的一些区别

HTTP1.0最早在网页中使用是在1996年，HTTP1.1是当前使用最为广泛的HTTP协议。

主要区别主要体现在：

  1. **缓存处理，**在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
  5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTPS

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。SSL目前的版本是3.0，被IETF（Internet Engineering Task Force）定义在RFC 6101中，之后IETF对SSL 3.0进行了升级，于是出现了TLS（Transport Layer Security） 1.0，定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词。

握手过程：

  1. 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端；
  2. 服务端接收到客户端所有的Cipher后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法，并将自己的身份信息以证书的形式发回给客户端。证书中还包含了公钥、颁证机构、网址 失效日期等等。
  3. 客户端获得网站证书之后浏览器要做以下工作：

  • 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

  • 生成随机密码：如果证书受信任，或者是用户接受了不受信的证书，客户端会生成一串随机数的密码，并用证书中提供的公钥加密。

  • 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给服务端。

  1. 服务端接收客户端发来的数据之后要做以下的操作：
    • 使用自己的私钥将信息解密取出密码，使用密码解密客户端发来的握手消息，并验证HASH是否与客户端发来的一致。
    • 使用密码加密一段握手消息，发送给客户端。
  2. 客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前客户端生成的随机密码并利用对称加密算法进行加密。
https通信原理流程图

HTTPS一般使用的加密与HASH算法如下：

  1. 非对称加密算法：RSA，DSA/DSS
  2. 对称加密算法：AES，RC4，3DES
  3. HASH算法：MD5，SHA1，SHA256

HTTPS与HTTP的一些区别

  1. HTTPS协议需要到CA申请证书；

  2. HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的；

  3. HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443；

  4. HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

    HTTP2.0

    • 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
    • 多路复用（MultiPlexing），即连接共享，每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
    • **header压缩，**如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
    • 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。目前，有大多数网站已经启用HTTP2.0，例如YouTuBe，淘宝等网站，利用chrome控制台可以查看是否启用H2

Websocket

WebSocket是为解决客户端与服务端实时通信而产生的技术。websocket协议本质上是一个基于tcp的协议，是先通过HTTP/HTTPS协议发起一条特殊的http请求进行握手后创建一个用于交换数据的TCP连接，此后服务端与客户端通过此TCP连接进行实时通信。

简介

  1. 服务器可以主动向客户端推送信息；
  2. 建立在TCP协议上，服务端比较容易实现；
  3. 性能开销比较小，通信高效；
  4. 可以发送文本，也可以发送二进制数据；

Websocket和HTTP协议的关系

同样作为应用层的协议，WebSocket在现代的软件开发中被越来越多的实践，和HTTP有很多相似的地方，这里将它们简单的做一个纯个人、非权威的比较：

相同点
  1. 都是基于TCP的应用层协议。
  2. 都使用Request/Response模型进行连接的建立。
  3. 在连接的建立过程中对错误的处理方式相同，在这个阶段WS可能返回和HTTP相同的返回码。
  4. 都可以在网络中传输数据。
不同点
  1. WS使用HTTP来建立连接，但是定义了一系列新的header域，这些域在HTTP中并不会使用。
  2. WS的连接不能通过中间人来转发，它必须是一个直接连接。
  3. WS连接建立之后，通信双方都可以在任何时刻向另一方发送数据。
  4. WS连接建立之后，数据的传输使用帧来传递，不再需要Request消息。
  5. WS的数据帧有序。

什么是 Socket？工作流程是怎样的？

Socket 又称网络套接字，是一种操作系统提供的进程间通信机制。

工作流程：

  1. 服务端先用 socket 函数来建立一个套接字，并调用 listen 函数，使服务端的这个端口和 IP 处于监听状态，等待客户端的连接
  2. 客户端用 socket 函数建立一个套接字，设定远程 IP 和端口，并调用 connect 函数
  3. 服务端用 accept 函数来接受远程计算机的连接，建立起与客户端之间的通信
  4. 完成通信以后，最后使用 close 函数关闭 socket 连接。

HTTP中GET与POST的区别，注意最后一条

  1. GET在浏览器回退时是无害的，而POST会再次提交请求。
  2. GET产生的URL地址可以被Bookmark，而POST不可以。
  3. GET请求会被浏览器主动cache，而POST不会，除非手动设置。
  4. GET请求只能进行url编码，而POST支持多种编码方式。
  5. GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
  6. GET请求在URL中传送的参数是有长度限制的，而POST没有。
  7. 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
  8. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
  9. GET参数通过URL传递，POST放在Request body中。
  10. GET产生一个TCP数据包，POST产生两个TCP数据包。

Cookie存在哪

  1. 如果设置了过期时间，Cookie存在硬盘里
  2. 没有设置过期时间，Cookie存在内存里

COOKIE和SESSION的区别和关系

  1. COOKIE保存在客户端，而SESSION则保存在服务器端
  2. 从安全性来讲，SESSION的安全性更高
  3. 从保存内容的类型的角度来讲，COOKIE只保存字符串（及能够自动转换成字符串）
  4. 从保存内容的大小来看，COOKIE保存的内容是有限的，比较小，而SESSION基本上没有这个限制
  5. 从性能的角度来讲，用SESSION的话，对服务器的压力会更大一些
  6. SEEION依赖于COOKIE，但如果禁用COOKIE，也可以通过url传递

nginx的负载均衡实现方式

  1. 轮询
  2. 用户IP哈希
  3. 指定权重
  4. fair（第三方）
  5. url_hash（第三方）

网络IO模型

  1. 阻塞IO
  2. 非阻塞IO
  3. 多路复用IO
  4. 信号驱动IO
  5. 异步IO

阻塞IO

场景描述：

​ 老李去火车站买票，排队三天买到一张退票。

网络模型：

​ 在这个模型中，应用程序为了执行这个read操作，会调用相应的一个system call，将系统控制权交给内核，然后就进行等待（这个等待的过程就是被阻塞了），内核开始执行这个system call，执行完毕后会向应用程序返回响应，应用程序得到响应后，就不再阻塞，并进行后面的工作。

优点：能够及时返回数据，无延迟。

缺点：对用户来说处于等待就要付出性能代价。

非阻塞IO

场景描述：

​ 老李去火车站买票，隔12小时去火车站问有没有退票，三天后买到一张票。

网络模型：

​ 当用户进程发出read操作时，调用相应的system call，这个system call会立即从内核中返回。但是在返回的这个时间点，内核中的数据可能还没有准备好，也就是说内核只是很快就返回了system call，只有这样才不会阻塞用户进程，对于应用程序，虽然这个IO操作很快就返回了，但是它并不知道这个IO操作是否真的成功了，为了知道IO操作是否成功，应用程序需要主动的循环去问内核。

优点：能够在等待的时间里去做其他的事情。

缺点：任务完成的响应延迟增大了，因为每过一段时间去轮询一次read操作，而任务可能在两次轮询之间的任意时间完成，这对导致整体数据吞吐量的降低。

多路复用IO

场景描述：

  1. select/poll：老李去火车站买票，委托黄牛，然后每隔6小时电话黄牛询问，黄牛三天内买到票，然后老李去火车站交钱领票。

    1. epoll：老李去火车站买票，委托黄牛，黄牛买到后即通知老李去领，然后老李去火车站交钱领票。

网络模型：

IO多路转接是多了一个select函数，select函数有一个参数是文件描述符集合，对这些文件描述符进行循环监听，当某个文件描述符就绪时，就对这个文件描述符进行处理。

IO多路转接是属于阻塞IO，但可以对多个文件描述符进行阻塞监听，所以效率较阻塞IO的高。

信号驱动IO

场景描述：

​ 老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李，然后老李去火车站交钱领票。

网络模型：

应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGIO信号进行捕捉，并且调用我的信号处理函数来获取数据报。

异步IO

场景描述：

​ 老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李并快递送票上门。

网络模型：

当应用程序调用aio_read时，内核一方面去取数据报内容返回，另一方面将程序控制权还给应用进程，应用进程继续处理其他事情，是一种非阻塞的状态。

当内核中有数据报就绪时，由内核将数据报拷贝到应用程序中，返回aio_read中定义好的函数处理程序。

RSS