网络——HTTP协议详解（五）

概述

Http协议都是我们最常打交道的网络应用层协议，基于TCP连接。

HTTP报文

继承概念

http报文可以分为请求报文和响应报文，格式大同小异。

主要分为三个部分：

  • 1）起始行；
  • 2）首部；
  • 3）主体。

请求报文格式：

1
2
3
4
<method> <request-url> <version>
<headers>
 
<entity-body>

响应报文格式：

1
2
3
4
<version> <status> <reason-phrase>
<headers>
 
<entity-body>

从请求报文格式和响应报文格式可以看出，两者主要在起始行上有差异。

这里稍微解释一下各个标签：

1
2
3
4
5
<method> 指请求方法，常用的主要是Get、 Post、Head 还有其他一些我们这里就不说了，有兴趣的可以自己查阅一下
<version> 指协议版本，现在通常都是Http/1.1了
<request-url> 请求地址
<status> 指响应状态码， 我们熟悉的200、404等等
<reason-phrase> 原因短语，200 OK 、404 Not Found 这种后面的描述就是原因短语，通常不必太关注。

method

最常用的就是GET和POST。

通过Get方法发起请求时，会将请求参数拼接在request-url尾部，格式是url?param1=xxx¶m2=xxx&[…]，所以通过GET方法发起的请求参数不能够太长。
另外get最好作为读取或者获取资源，不应该有其他的副作用

而通过POST方法发起的请求是将参数放在请求体中的，所以不会有GET参数的这些问题。

但以上只限于浏览器请求的情形，实际上对于HTTP协议来说，get和post没有什么区别，get也可以有body。在安全方面讲，都不够安全，毕竟消息暴漏在传输过程中。

状态码

HTTP状态码共分为5种类型：

网络——HTTP协议详解（五）_2021-03-30-14-09-00.png

在请求报文和响应报文中都可以携带一些信息，通过与其他部分配合，能够实现各种强大的功能。这些信息位于起始行之下与请求实体之间，以键值对的形式，称之为首部。每条首部以回车换行符结尾，最后一个首部额外多一个换行，与实体分隔开。

网络——HTTP协议详解（五）_2021-03-30-14-09-52.png

实体

请求发送的资源，或是响应返回的资源。

版本

HTTP/0.9

该版本极其简单，只有一个命令GET：

GET /index.html

上面命令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html。

协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式：

1
2
3
<html>
  <body>Hello World</body>
</html>

服务器发送完毕，就关闭TCP连接。

HTTP/1.0

首先，任何格式的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。

其次，除了GET命令，还引入了POST命令和HEAD命令。

再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。

其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。

HTTP/1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。

为了解决这个问题，有些浏览器在请求时，用了一个非标准的Connection字段：

Connection: keep-alive

但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP/1.1

HTTP/1.1进一步完善了 HTTP 协议

  1. 持久连接

    TCP连接默认不关闭，可以被多个请求复用，客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接

  2. 管道机制

    即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。

    举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。

  3. 分块传输

    对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用”流模式”（stream）取代”缓存模式”（buffer）。

  4. Host

    客户端请求的头信息新增了Host字段，用来指定服务器的域名：
    Host: example.com

    有了Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为”队头堵塞”（Head-of-line blocking）。

为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。

HTTP/2

  1. 二进制

    HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”（frame）：头信息帧和数据帧。

  2. 多工

    HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”。

    举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。

    这样双向的、实时的通信，就叫做多工（Multiplexing）。

  3. 数据流

    因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

    HTTP/2 将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。

    数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。

    客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。

  4. 头信息压缩

    HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如Cookie和User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。

    HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用gzip或compress压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

  5. 服务器推送

    HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。

    常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。

HTTP和RPC

HTTP 和 RPC 其实是两个维度的东西， HTTP 指的是通信协议。

而 RPC 则是远程调用，其对应的是本地调用。

RPC 的通信可以用 HTTP 协议，也可以自定义协议，是不做约束的。主要用来来屏蔽这些底层调用细节，使得我们编码上还是和之前本地调用相差不多。

HTTPS

基础

简单的说：Http + 加密 + 认证 + 完整性保护 = Https。

传统的Http协议是一种应用层的传输协议，Http直接与TCP协议通信。

其本身存在一些缺点：

  • Http协议使用明文传输，容易遭到窃听；
  • Http对于通信双方都没有进行身份验证，通信的双方无法确认对方是否是伪装的客户端或者服务端；
  • Http对于传输内容的完整性没有确认的办法，往往容易在传输过程中被劫持篡改。

因此，在一些需要保证安全性的场景下，比如涉及到银行账户的请求时，Http无法抵御这些攻击。 Https则可以通过增加的SSL\TLS，支持对于通信内容的加密，以及对通信双方的身份进行验证。

加密原理

近代密码学中加密的方式主要有两类：

1）对称秘钥加密；
2）非对称秘钥加密。

对称秘钥加密是指加密与解密过程使用同一把秘钥。这种方式的优点是处理速度快，但是如何安全的从一方将秘钥传递到通信的另一方是一个问题。

非对称秘钥加密是指加密与解密使用两把不同的秘钥。这两把秘钥，一把叫公开秘钥，可以随意对外公开。一把叫私有秘钥，只用于本身持有。得到公开秘钥的客户端可以使用公开秘钥对传输内容进行加密，而只有私有秘钥持有者本身可以对公开秘钥加密的内容进行解密。这种方式克服了秘钥交换的问题，但是相对于对称秘钥加密的方式，处理速度较慢。

SSL\TLS的加密方式则是结合了两种加密方式的优点。首先采用非对称秘钥加密，将一个对称秘钥使用公开秘钥加密后传输到对方。对方使用私有秘钥解密，得到传输的对称秘钥。之后双方再使用对称秘钥进行通信。这样即解决了对称秘钥加密的秘钥传输问题，又利用了对称秘钥的高效率来进行通信内容的加密与解密。

网络——socket详解（四）

Socket与HTTP的区别

Http协议是基于TCP链接的。

Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。

Http连接：http连接就是所谓的短连接，及客户端向服务器发送一次请求，服务器端相应后连接即会断掉。

socket连接：socket连接及时所谓的长连接，理论上客户端和服务端一旦建立连接，则不会主动断掉；

Socket读写的简单过程理解

当客户端和服务器使用TCP协议进行通信时，客户端封装一个请求对象req，将请求对象req序列化成字节数组，然后通过套接字socket将字节数组发送到服务器，服务器通过套接字socket读取到字节数组，再反序列化成请求对象req，进行处理，处理完毕后，生成一个响应对应res，将响应对象res序列化成字节数组，然后通过套接字将字节数组发送给客户端，客户端通过套接字socket读取到字节数组，再反序列化成响应对象。

Socket读写的细节过程分析

我们平时用到的套接字其实只是一个引用(一个对象ID)，这个套接字对象实际上是放在操作系统内核中。这个套接字对象内部有两个重要的缓冲结构，一个是读缓冲(read buffer)，一个是写缓冲(write buffer)，它们都是有限大小的数组结构。

当我们对客户端的socket写入字节数组时(序列化后的请求消息对象req)，是将字节数组拷贝到内核区套接字对象的write buffer中，内核网络模块会有单独的线程负责不停地将write buffer的数据拷贝到网卡硬件，网卡硬件再将数据送到网线，经过一些列路由器交换机，最终送达服务器的网卡硬件中。

同样，服务器内核的网络模块也会有单独的线程不停地将收到的数据拷贝到套接字的read buffer中等待用户层来读取。最终服务器的用户进程通过socket引用的read方法将read buffer中的数据拷贝到用户程序内存中进行反序列化成请求对象进行处理。然后服务器将处理后的响应对象走一个相反的流程发送给客户端，这里就不再具体描述。

阻塞

我们注意到write buffer空间都是有限的，所以如果应用程序往套接字里写的太快，这个空间是会满的。一旦满了，写操作就会阻塞，直到这个空间有足够的位置腾出来。不过有了NIO(非阻塞IO)，写操作也可以不阻塞，能写多少是多少，通过返回值来确定到底写进去多少，那些没有写进去的内容用户程序会缓存起来，后续会继续重试写入。

同样我们也注意到read buffer的内容可能会是空的。这样套接字的读操作(一般是读一个定长的字节数组)也会阻塞，直到read buffer中有了足够的内容(填充满字节数组)才会返回。有了NIO，就可以有多少读多少，无须阻塞了。读不够的，后续会继续尝试读取。

ack

比如当写缓冲的内容拷贝到网卡后，是不会立即从写缓冲中将这些拷贝的内容移除的，而要等待对方的ack过来之后才会移除。如果网络状况不好，ack迟迟不过来，写缓冲很快就会满的。

包头

核的网络模块会将缓冲区的消息进行分块传输，如果缓冲区的内容太大，是会被拆分成多个独立的小消息包的。并且还要在每个消息包上附加上一些额外的头信息，比如源网卡地址和目标网卡地址、消息的序号等信息，到了接收端需要对这些消息包进行重新排序组装去头后才会扔进读缓冲中。

速率

有个问题那就是如果读缓冲满了怎么办，网卡收到了对方的消息要怎么处理？一般的做法就是丢弃掉不给对方ack，对方如果发现ack迟迟没有来，就会重发消息。那缓冲为什么会满？是因为消息接收方处理的慢而发送方生产的消息太快了，这时候tcp协议就会有个动态窗口调整算法来限制发送方的发送速率，使得收发效率趋于匹配。如果是udp协议的话，消息一丢那就彻底丢了。

网路——TCP三次握手和四次握手（三）

TCP协议

TCP提供一种面向连接的、可靠的字节流服务。面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。

确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；

同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；

终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放

建立连接（三次握手）

  1. TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；

  2. TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。

  3. TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。

  4. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。

  5. 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

释放连接（四次握手）

  1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

  2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

  3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

  4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

  5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ *∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

  6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么TCP客户端最后还要发送一次确认呢？

防止网络滞留，导致重复连接。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

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

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

网络——网络分层详解（二）

为什么要分层？

俩个计算机在物理意义上是互不认识的，只有通过一系列的协议将它们联系起来，例如：两个计算机之间怎么进行识别？以及怎么才能知道对方的地址？以及不同计算机应用程序怎么知道是给自己传递的数据，还有不同的通信数据格式怎么来规定等等一系列的问题。

如果各种问题都写成一套协议来规定双方通信的规则，但是呢？万一其中哪些规则通信中出现问题，影响到了其他规则，最常见的就是数据包，一个数据包中如果包含各种各样的协议，不就乱套了。

为了能够把它设计的更好，决定采用分层划分的结构，既能规定不同层的完成的功能，又能实现层与层之间的改动而不相互影响，这就是我们经常听到网络划分层次的好处。

如何进行分层？

起初网络分层是标准的七层，也就是我们所说的 OSI 七层模型。

网络——网络分层详解（二）_2021-03-29-13-31-51.png

TCP/IP 四层模型和 TCP/IP 五层模型是以 OSI 七层优化而来，把某些层进行合并了，其实本质上还是相同的。

网络——网络分层详解（二）_2021-03-29-13-53-27.png

每一层的作用？

物理层

物理层，顾名思义，用物理手段将电脑连接起来，主要用来传输0、1信号，而0、1信号毕竟没有任何的现实意义，所有我们用另一层用来规定不同0、1组合的意义是什么。

数据链路层

么我们在数据链路层规定一套协议，专门的给0、1信号进行分组，以及规定不同的组代表什么意思，从而双方计算机都能够进行识别，这个协议就是“以太网协议”。

但是问题又来了，我们要发送给对方计算机，怎么标识对方以及怎么知道对方的地址呢？

MAC地址：它就是作为网络中计算机设备的唯一标识，从计算机在厂商生产出来就被十六进制的数标识为MAC地址。

既然我们知道了用MAC地址作为标识，那么怎么才能知道我们要进行通信的计算机MAC地址呢？

广播：广播可以帮助我们能够知道对方的 MAC 地址。那么既然知道了MAC地址就可以通信了？没有想得那么简单，广播中还存在两种情况，一种是，在同一子网络下（同一局域网下）的计算机是通过 ARP 协议获取到对方 MAC地址的。不同自网络中（不同局域网）中是交给两个局域网的网关（路由器）去处理的。

网络层

网络层的由来是因为在数据链路层中我们说说两台计算机之间的通信是分为同一子网络和不同子网络之间，那么问题就来了，怎么判断两台计算机是否在同一子网络（局域网）中？这就是网络层要解决的问题。

IP协议：

我们可以将 IP 地址抽象成一种逻辑上的地址，也就是说 MAC 地址是物理上的地址，就是定死了。IP 地址呢，是动态分配的，不是固定死的。

既然我们通过 IP 地址来判断两个计算机是否处于同一局域网中，那么首先要知道对方的 IP 地址吧？DNS 解析想必大家都知道，可以将域名解析为 IP 地址。好了，我们知道两台计算机的 IP 地址了，怎么进行判断是否同一局域网中？

子网掩码：

子网掩码也是由 32 个二进制位组成的，但是只能用 0 或 1 来表示，如：11111111.11111111.11111111.00000000。

两台计算机的 IP 地址分别和子网掩码进行一种运算（AND 运算），如果结果相同，两台计算机就在同一局域网中，否则就不在同一局域网中。

传输层

传输层的主要功能就是为了能够实现“端口到端口”的通信。计算机上运行的不同程序都会分配不同的端口，所以才能使得数据能够正确的传送给不同的应用程序。

UDP 协议：

加入端口号也需要一套规则，那就是 UDP 协议，但是 UDP协议有个缺点，一旦进行通信，就不知道对方是否接收到数据了，我们再定义一套规则，让其可以和对方进行确认，那么 TCP 出现了。

TCP 协议：

我们通常说 TCP 三次握手和四次挥手，没错，这就是传输层中完成的，TCP 三次握手涉及到的内容贼多，都可以单独写一篇长文，这里不多陈述，知道它是在传输层中完成的以及它的作用是什么，能够认识到它就好了。

应用层协议

应用层的功能就是规定了应用程序的数据格式。我们经常用得到的电子邮件、HTTP协议、以及FTP数据的格式，就是在应用层定义的。

应用层是最高一层，直接面向用户，它的数据包会放在 TCP 的数据包的“数据”部分，那么整个五层的数据包就会变成一下这样。

网络——网络分层详解（二）_2021-03-29-14-11-04.png

JAVA基础——BIO、NIO、AIO

概述

通常IO进程包括等待数据、拷贝数据与操作数据，其中与系统内核相关的是等待数据与拷贝数据，绝大部分时间也花在这里。

阻塞

JAVA基础——BIO、NIO、AIO_2021-03-30-09-17-00.png

阻塞分为两部分：

  1. CPU把数据从磁盘读到内核缓冲区。
  2. CPU把数据从内核缓冲区拷贝到用户缓冲区。

非阻塞

JAVA基础——BIO、NIO、AIO_2021-03-30-09-21-32.png

非阻塞IO发出read请求后发现数据没准备好，会继续往下执行，此时应用程序会不断轮询polling内核询问数据是否准备好，当数据没有准备好时，内核立即返回EWOULDBLOCK错误。直到数据被拷贝到应用程序缓冲区，read请求才获取到结果。并且你要注意！这里最后一次 read 调用获取数据的过程，是一个同步的过程，是需要等待的过程。这里的同步指的是内核态的数据拷贝到用户程序的缓存区这个过程。

IO多路复用

JAVA基础——BIO、NIO、AIO_2021-03-30-09-23-13.png

非阻塞情况下无可用数据时，应用程序每次轮询内核看数据是否准备好了也耗费CPU，能否不让它轮询，当内核缓冲区数据准备好了，以事件通知当机制告知应用进程数据准备好了呢？应用进程在没有收到数据准备好的事件通知信号时可以忙写其他的工作。此时IO多路复用就派上用场了。

实现一个线程监控多个IO请求，哪个IO有请求就把数据从内核拷贝到进程缓冲区，拷贝期间是阻塞的！

像select、poll、epoll 都是I/O多路复用的具体的实现。

select是第一版IO复用，提出后暴漏了很多问题。

  1. select 会修改传入的参数数组，这个对于一个需要调用很多次的函数，是非常不友好的。
  2. select 如果任何一个sock(I/O stream)出现了数据，select 仅仅会返回，但不会告诉是那个sock上有数据，只能自己遍历查找。
  3. select 只能监视1024个链接。
  4. select 不是线程安全的，如果你把一个sock加入到select, 然后突然另外一个线程发现这个sock不用，要收回，这个select 不支持的。

poll 修复了 select 的很多问题。

  1. poll 去掉了1024个链接的限制。
  2. poll 从设计上来说不再修改传入数组。

但是poll仍然不是线程安全的， 这就意味着不管服务器有多强悍，你也只能在一个线程里面处理一组 I/O 流。

epoll 可以说是 I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题， 比如：

  1. epoll 现在是线程安全的。
  2. epoll 现在不仅告诉你sock组里面数据，还会告诉你具体哪个sock有数据，你不用自己去找了。
  3. epoll 内核态管理了各种IO文件描述符， 以前用户态发送所有文件描述符到内核态，然后内核态负责筛选返回可用数组，现在epoll模式下所有文件描述符在内核态有存，查询时不用传文件描述符进去了。

异步IO

JAVA基础——BIO、NIO、AIO_2021-03-30-09-41-09.png

然后你会发现上面的提到过的操作都不是真正的异步，因为两个阶段总要等待会儿！而真正的异步 I/O 是内核数据准备好和数据从内核态拷贝到用户态这两个过程都不用等待。

很庆幸，Linux给我们准备了aio_read跟aio_write函数实现真实的异步，当用户发起aio_read请求后就会自动返回。内核会自动将数据从内核缓冲区拷贝到用户进程空间，应用进程啥都不用管。

同步阻塞

此时一个线程维护一个连接，该线程完成数据到读写跟处理到全部过程，数据读写时时线程是被阻塞的。

同步非阻塞

非阻塞的意思是用户线程发出读请求后，读请求不会阻塞当前用户线程，不过用户线程还是要不断的去主动判断数据是否准备OK了。此时还是会阻塞等待内核复制数据到用户进程。他与同步BIO区别是使用一个连接全程等待

BIO

同步阻塞IO

使用一个独立的线程维护一个socket连接，随着连接数量的增多，对虚拟机造成一定压力。

使用流来读取数据，流是阻塞的，当没有可读／可写数据时，线程等待，会造成资源的浪费。

NIO

同步非阻塞IO

服务器端保存一个Socket连接列表，然后对这个列表进行轮询，如果发现某个Socket端口上有数据可读时说明读就绪，则调用该socket连接的相应读操作。如果发现某个 Socket端口上有数据可写时说明写就绪，则调用该socket连接的相应写操作。如果某个端口的Socket连接已经中断，则调用相应的析构方法关闭该端口。这样能充分利用服务器资源，效率得到了很大提高，在进行IO操作请求时候再用个线程去处理，是一个请求一个线程。Java中使用Selector、Channel、Buffer来实现上述效果。

JAVA基础——BIO、NIO、AIO_2021-03-30-10-23-33.png

每个线程中包含一个Selector对象，它相当于一个通道管理器，可以实现在一个线程中处理多个通道的目的，减少线程的创建数量。远程连接对应一个channel，数据的读写通过buffer均在同一个channel中完成，并且数据的读写是非阻塞的。通道创建后需要注册在selector中，同时需要为该通道注册感兴趣事件（客户端连接服务端事件、服务端接收客户端连接事件、读事件、写事件），selector线程需要采用轮训的方式调用selector的select函数，直到所有注册通道中有兴趣的事件发生，则返回，否则一直阻塞。而后循环处理所有就绪的感兴趣事件。以上步骤解决BIO的两个瓶颈：

  1. 不必对每个连接分别创建线程。
  2. 数据读写非阻塞。

AIO

AIO是异步非阻塞IO，相比NIO更进一步，进程读取数据时只负责发送跟接收指令，数据的准备工作完全由操作系统来处理。

  • 同步

线程需要等待IO的操作。

  • 异步

线程不需要等待IO的操作。

阻塞和非阻塞的区别

  • 阻塞

拷贝数据线程要阻塞在那里。

  • 非阻塞

拷贝数据的过程线程可以去做其他事。

面向流和面向缓冲区

Java NIO和BIO之间的第一个重要区别是BIO是面向流的，其中NIO是面向缓冲区的。

面向流的Java BIO意味着您可以从流中一次读取一个或多个字节。你对读取的字节做什么取决于你。它们不会缓存在任何地方。此外，您无法在流中的数据中前后移动。如果需要在从流中读取的数据中前后移动，则需要先将其缓存在缓冲区中。

Java NIO的面向缓冲区的方法略有不同。数据被读入缓冲区，稍后处理该缓冲区。你可以根据需要在缓冲区中前后移动。这使你在处理过程中具有更大的灵活性。但是，你还需要检查缓冲区是否包含完整处理所需的所有数据。并且，你需要确保在将更多数据读入缓冲区时，不要覆盖尚未处理的缓冲区中的数据。

NIO 三大核心

JAVA基础——BIO、NIO、AIO_2021-03-29-15-41-49.png

  1. 每个 Channel 对应一个 Buffer。
  2. Selector 对应一个线程，一个线程对应多个 Channel。
  3. 该图反应了有三个 Channel 注册到该 Selector。
  4. 程序切换到那个 Channel 是由事件决定的（Event）。
  5. Selector 会根据不同的事件，在各个通道上切换。
  6. Buffer 就是一个内存块，底层是有一个数组。
  7. 数据的读取和写入是通过 Buffer，但是需要flip()切换读写模式。而 BIO 是单向的，要么输入流要么输出流。

Selectors

Java NIO的选择器允许单个线程监视多个输入通道。你可以使用选择器注册多个通道，然后使用单个线程“选择”具有可用于处理的输入的通道，或者选择准备写入的通道。这种选择器机制使单个线程可以轻松管理多个通道。

IO多路复用：IO多路复用模型是建立在内核提供的多路分离函数select基础上的，查询每个socket是否有到达事件，如果有就通知，使用select可以避免非阻塞模型中轮询情况

AIO

异步非阻塞I/O模型,线程既没有参与等待过程也没有参与拷贝过程。

网络——DNS解析（一）

完整流程

  1. 根据域名和 DNS 解析到服务器的IP地址 (DNS + CDN)
  2. 通过ARP协议获得IP地址对应的物理机器的MAC地址
  3. 浏览器对服务器发起 TCP 3 次握手
  4. 建立 TCP 连接后发起 HTTP 请求报文
  5. 服务器响应 HTTP 请求，将响应报文返回给浏览器
  6. 短连接情况下，请求结束则通过 TCP 四次挥手关闭连接，长连接在没有访问服务器的若干时间后，进行连接的关闭
  7. 浏览器得到响应信息中的 HTML 代码， 并请求 HTML 代码中的资源（如js、css、图片等）
  8. 浏览器对页面进行渲染并呈现给用户

DNS 解析过程

网络——一次HTTP请求的完整过程_2021-01-22-14-55-42.png

三种类型的 DNS 服务器，根 DNS 服务器，顶级域 DNS 服务器和权威 DNS 服务器。

  1. 首先浏览器会检查浏览器自身的DNS缓存中，是否有域名对应的DNS缓存(chrome缓存1分钟，大概有1000条缓存)，没有的话进入第二步，否则解析完成
  2. 接下来去查看系统的hosts文件(C:\Windows\System32\drivers\etc)是否有域名对应的IP地址，如果找到则停止解析，否则进入第三步
  3. 浏览器发起DNS系统调用，向本地配置的首选DNS服务器发起域名解析请求(通过UDP协议，向DNS的53端口发起请求)
  4. 首先请求会在运营商的DNS服务器(本地服务器)上进行请求，如果找到对应的条目，且没有过期，则解析成功，否则进入第五步
  5. 运营商的DNS服务器，根据解析请求，迭代查询，首先找到根域名服务器的IP地址(这个DNS服务器内置13台根域DNS的IP地址)，然后找到根域的DNS地址，发送请求
  6. 根域服务器收到请求后，根据域名，返回对应的顶级域的服务器ip地址，并返回给运营商DNS服务器
  7. 运营商DNS服务器接收到根域名服务器传回来的顶级域名服务器IP地址后，向顶级域名服务器发送请求
  8. 顶级域名服务器接收到请求后，返回该域名对应的权威域名服务器的ip地址，并返回给运行商DNS服务器。
  9. 运营商DNS服务器获得权威域名服务器的响应信息后，返回给请求的主机，DNS解析完成。

DNS主要是通过UDP通信，报文结构主要分为头部Header、查询部分Question、应答部分Answer/Authority/Addition。

|