来源于牛客大佬 原来是笑傲君殿下 的无私分享。

==计算机网络==

OSI七层模型

物理层

​ 可以通过网线也可以通过无线连接两台设备。当数据传送到物理层时会转化为比特数据，比如010101，而比特数据会转化为光信号或电信号传输到另一台设备上。而这一过程就需要物理层完成。

主要协议：RJ45、CLOCK、IEEE802.3 （中继器，集线器，网关）

数据链路层

涉及MAC地址及网卡地址。当一台设备连接到路由器，路由器连接到光猫上，而光猫则连通电信网络。当你从这台设备发出信息时，首先数据到达路由器，在通过路由器数据到达光猫，然后到达电信公网。在数据从设备到达路由器这一过程中是通过识别MAC地址完成的。也就是从一个节点到达另一个节点。而IP则是直接标识源和目的地。(即你的设备地址，和你所发送的设备地址)。

主要协议：PPP、FR、HDLC、VLAN、MAC （网桥，交换机）

网络层

这一层开始实现设备到设备之间的通信。

（1）IP即互联协议，Ip为网络设备提供逻辑地址。

（2）并且把刚刚从传输层送来的数据送到“目的地”，那么网络层则为这些数据提供最佳的路线。

主要协议：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）

传输层

（1）传输层为应用程序提供端口供应用层使用。

（2）当传输较大的文件时会将文件分段，那么为了保证这些数据正常的顺序，还要对数据进行重组，包括流量控

制；差错控制，这些都由传输层完成控制。

主要协议：TCP、UDP、SPX

会话层

会将不同的应用程序的数据隔离起来。比如QQ与微信的隔离，使两个应用程序之间的数据进行隔离，防止串流。当然，如果想要共享两个软件之间的数据，可以通过应用层对应的接口进行共享。

主要协议：NFS、SQL、NETBIOS、RPC

表示层

对应用数据转换。比如说你在QQ聊天时，音频通过对应软件的接口，传递给声卡，声卡把这些数据进行一个编码，变成比特数据传送到另一个人的设备上，然后在这台设备进行解码转化成语音。

主要协议：JPEG、MPEG、ASII

应用层

最接近用户的一层。提供接口，使应用程序能够使用一些网络协议。

主要协议：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

TCP/IP五层模型

TCP/IP五层模型：1、物理层：2、数据链路层：3、网络层：4、传输层：5、应用层；

TCP/IP四层模型：

1、数据链路层(物理层直接叫做物理传输介质。)；2、网络层；3、传输层；4、应用层；

• 应用层：应用层是在用户空间实现的，负责处理众多业务逻辑，如文件传输、网络管理。
• 传输层：为应用程序隐藏了数据包跳转的细节，负责数据包的收发、链路超时重连等。
• 网络层：能够使得不同应用类型的数据在Internet上通畅地传输。
• 数据链路层：实现网卡接口的网络驱动，以处理数据在以太网等物理媒介上的传输。

ICMP协议

ICMP，因特网控制报文协议。它是IPv4协议族中的一个子协议，用于IP主机、路由器之间传递控制消息。控制消息是在网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然不传输用户数据，但是对于用户数据的传递起着重要的作用。

ICMP报文信息

​ ICMP报文包含在IP数据报中，IP报头在ICMP报文的最前面。一个ICMP报文包括IP报头（至少20字节）、ICMP报头（至少八字节）和ICMP报文（属于ICMP报文的数据部分）。当IP报头中的协议字段值为1时，就说明这是一个ICMP报文。ICMP报头如下图所示。

各字段说明

• 类型：占一字节，标识ICMP报文的类型，目前已定义了14种，从类型值来看ICMP报文可以分为两大类。第一类是取值为1~127的差错报文，第2类是取值128以上的信息报文。
• 代码：占一字节，标识对应ICMP报文的代码。它与类型字段一起共同标识了ICMP报文的详细类型。
• 校验和：这是对包括ICMP报文数据部分在内的整个ICMP数据报的校验和，以检验报文在传输过程中是否出现了差错。其计算方法与在我们介绍IP报头中的校验和计算方法是一样的。
• 标识：占两字节，用于标识本ICMP进程，但仅适用于回显请求和应答ICMP报文，对于目标不可达ICMP报文和超时ICMP报文等，该字段的值为0。

TCP

TCP（控制传输协议），是一种面向连接的、可靠的、基于字节流的传输层通信协议。是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

TCP报头信息

TCP报文是TCP层传输的数据单元，也叫报文段。

1、端口号：用来标识同一台计算机的不同的应用进程。

1）源端口：源端口和IP地址的作用是标识报文的返回地址。

2）目的端口：端口指明接收方计算机上的应用程序接口。

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

2、序号和确认号：是TCP可靠传输的关键部分。序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。确认号，即ACK，指明下一个期待收到的字节序号如N，则表明序号N之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。

3、数据偏移／首部长度：4bits。由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15*32/8 = 60，故报头最大长度为60字节。首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值。

4、保留：为将来定义新的用途保留，现在一般置0。

5、控制位：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能。

1）URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。

2）ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。

3）PSH：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。

4）RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。

5）SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。

6）FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。

6、窗口：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bit字段，因而窗口大小最大为65535。

7、校验和：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。由发送端计算和存储，并由接收端进行验证。

8、紧急指针：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

9、选项和填充：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。

10、数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

TCP元组

这些元组主要是用于端口复用的，对于一个连接来说，只要其中一个存在不同则可以区别这是一个不同的连接。

四元组：

源IP地址、目的IP地址、源端口、目的端口

五元组:

源IP地址、目的IP地址、协议号、源端口、目的端口

七元组:

源IP地址、目的IP地址、协议号、源端口、目的端口，服务类型以及接口索引

三次握手

​ （1）第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SEND 状态。首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

​ （2）第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

​ （3）第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。在socket编程中，客户端执行connect()时，将触发三次握手。

(PS:第三次握手的情况下，ACK数据包如果丢失，有两种情况，1、客户端接着发送数据包，服务器端收到数据包，这个时候数据包带有和ACK一样的信息，因此不需要进行重传。2、如果客户端没有发送数据包，那么过了2ms，服务器端会认为自己的ACK数据包丢失了，进行重传，这个时候客户端才重传对应的数据包。)

三次握手的目的

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。因此，需要三次握手才能确认双方的接收与发送能力是否正常。试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

初始序列号，ISN(Initial Sequence Number)：

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。三次握手的其中一个重要功能是客户端和服务端交换 ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

泛洪攻击：

​ 该攻击借助于TCP的三次握手实现的。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

解决措施：

​ 对于SYN泛洪攻击的防范，优化主机系统设置是常用的手段。如降低SYN timeout时间，使得主机尽快释放半连接的占用；又比如采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。

四次挥手

​ （1）第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

​ （2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

​ （3）第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。（这里是多出的一次挥手，主要原因在于可能双方连接断开的时候，数据的传输还没有完成，因此需要多一次等待数据传输完成。）

​ （4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

TIME_WAIT状态：客户端发送最后一次ACK之后，可能由于网络比较阻塞，该数据帧在传送过程中丢失了。服务器可能会再次进行确认，但是此时如果客户端已经进入CLOSE状态，不会理会其他的请求。因此，采用TIME_WAIT来保障如果网络比较阻塞，可以保证正常关闭TCP连接。TIME_WAIT其实并不能说是服务器还是客户端的状态。因为他其实是一个主动断开链接发起者的状态，在发送最后一次ACK后进入TIME_WAIT状态。

CLOSE_WAIT状态：在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。

2、流量控制，通常采用滑动窗口实现。**(滑动窗口的大小取决于接收方的窗口大小和信道大小)**，滑动窗口下的方式有

（1）停止等待协议，当发送窗口和接收窗口都等于1时，就是停止等待协议。发送端给接收端发送数据，等待接收端确认回复ACk，并停止发送新的数据包，开启计时器。数据包在计时器超时之前得到确认，那么计时器就会关闭，并发送下一个数据包。如果计时器超时，发送端就认为数据包丢失或被破坏，需要重新发送之前的数据包，说明数据包在得到确认之前，发送端需要存储数据包的副本。停止等待协议是发出一个帧后得到确认才发下一个，降低了信道的利用率。

（2）后退N帧协议，在发送完一个帧后，不用停下来等待确认，而是可以连续发送多个数据帧。收到确认帧时，任可发送数据，这样就减少了等待时间，整个通信的通吞吐量提高。如果前一个帧在超时时间内未得到确认，就认为丢失或被破坏，需要重发出错帧及其后面的所有数据帧。这样有可能有把正确的数据帧重传一遍，降低了传送效率。线路很差时，使用退后N帧的协议会浪费大量的带宽重传帧。

（3）选择重传协议，NAK：非确认帧，当在一定时间内没有收到某个数据帧的ACK时，回复一个NACK。在发送过程中，如果一个数据帧计时器超时，就认为该帧丢失或者被破坏，接收端只把出错的的帧丢弃，其后面的数据帧保存在缓存中，并向发送端回复NAK。发送端接收到NAK时，只发送出错的帧。如果落在窗口的帧从未接受过，那么存储起来，等比它序列号小的所有帧都按次序交给网络层，那么此帧才提交给网络层。接收端收到的数据包的顺序可能和发送的数据包顺序不一样。因此在数据包里必须含有顺序字符来帮助接受端来排序。选择重传协议可以避免重复传送那些正确到达接收端的数据帧。但是接收端要设置具有相当容量的缓存空间，这在许多情况下是不够经济的。

3、拥塞控制：拥塞，即对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。拥塞避免的方式主要包括慢启动，拥塞避免，快重传，快恢复。

1、慢启动：

​ 当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

2、拥塞避免：

​ 让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

3、快重传：

​ 那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传，快速重传做的事情有：

1. 把ssthresh设置为cwnd的一半

2. 把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)

3. 重新进入拥塞避免阶段。

   

4、快恢复：

1. 当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3
2. 再收到重复的ACK时，拥塞窗口增加1。
3. 收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

PS: 发送方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个。即发送方窗口的上限值 = Min [rwnd ,cwnd]。

安全性

校验和

​ TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。计算方法为：在发送方将整个报文段分为多个16位的段，然后将所有段进行反码相加，将结果存放在检验和字段中，接收方用相同的方法进行计算，如最终结果为检验字段所有位是全1则正确（UDP中也是全为1则正确），否则存在错误。

UDP

​ Internet 协议集支持一个无连接的传输协议，该协议称为用户数据报协议（UDP，User Datagram Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。

UDP传输的可靠性由应用层负责。常用的UDP端口号有：53（DNS）、69（TFTP）、161（SNMP），使用UDP协议包括：TFTP、SNMP、NFS、DNS、BOOTP。

UDP报头由4个域组成，其中每个域各占用2个字节，具体包括源端口号、目标端口号、数据包长度、校验值。

TCP与UDP的区别

1、连接方面区别

TCP面向连接（如打电话要先拨号建立连接）。

UDP是无连接的，即发送数据之前不需要建立连接。

2、安全方面的区别

TCP提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。

UDP尽最大努力交付，即不保证可靠交付。

3、传输效率的区别

TCP传输效率相对较低。

UDP传输效率高，适用于对高速传输和实时性有较高的通信或广播通信。

4、连接对象数量的区别

TCP连接只能是点到点、一对一的。

UDP支持一对一，一对多，多对一和多对多的交互通信。

HTTP

无状态：

1、协议对于事务处理没有记忆能力。

2、对同一个url请求没有上下文关系。

3、每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况。

4、服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器。

Cookies/Session

​ 这两个主要用于解决Http无状态连接的问题，会给每个会话创建对应的SessionID，会根据sessionID判断当前登陆的用户。

Cookie ，通俗地说就是当一个用户通过 HTTP 协议访问一个服务器的时候，这个服务器会将一些 Key/Value 键值对返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时这个用户下次访问这个服务器的时候，数据又被完整地带回给服务器。Cookie 是 HTTP 协议头中的一个字段，虽然 HTTP 协议本身对这个字段并没有多少限制，但是 Cookie 最终还是存储在浏览器里。

Session，实际上是一个对象，存储在服务器端的内存中，在session对象中也可以存储多条数据，每一条数据都有一个sessionid作为唯一标识。

利用cookie和session登录的原理：
客户输入账号密码进行登录，服务器端进行验证，验证成功则生成唯一的sessionId，并且在session对象中存储当前用户信息。服务器端将sessionId写入客户端cookie中，当客户端下次访问服务器端时cookie会被自动发送给服务器端，服务器端在cookie中拿到sessionId然后在服务器端的session对象中查找sessionId进行验证，验证成功说明用户是登陆状态，则可以为其响应只有在登陆状态才能响应的数据。

长连接

短连接

Web请求完整过程

1. 输入网址；

2. DNS根据网址递归查找对应的IP地址。

   浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。

   系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。

   路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。
   ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。

   递归搜索 – 你的ISP的DNS服务器从根域名服务器开始进行递归搜索，从**.com顶级域名服务器到Facebook的域名服务器**。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。

   

3. 建立对应的TCP连接，三次握手四次挥手。

4. 浏览器给web服务器发送一个HTTP请求。

5. 服务的永久重定向响应。（待选）

6. 浏览器跟踪对应的重定向地址。（待选）

7. 服务器处理请求。

8. 服务器发回HTML响应。

9. 浏览器解析对应的HTML响应

   1. 浏览器开始显示HTML
   2. 浏览器发送获取嵌入在HTML中的对象
   3. 浏览器发送异步（AJAX）请求

10. 关闭TCP连接。

HTTP状态码

1、消息(1XX)：

100 Continue，客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。

2、成功(2XX):

200 OK，请求已成功；

201 Created，请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。

3、**重定向(3XX)**：

300 Multiple Choices，被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。

301: 永久重定向，表示本网页永久性转移到另一个地址。

302：重定向，当响应码为302时，表示服务器要求浏览器重新再发一个请求，服务器会发送一个响应头Location，它指定了新请求的URL地址；

304: 服务器端会获取If-Modified-Since值，与index.html 的当前最后修改时间比对，如果相同，服务器会发响应码304，表示index.html与浏览器上次缓存的相 同，无需再次发送，浏览器可以显示自己的缓存页面，如果比对不同，那么说明index.html已经做了修 改，服务器会响应200。

4、请求错误（4XX）:

400 Bad Request，

​ 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。

​ 2、请求参数有误。

403 Forbidden，服务器已经理解请求，但拒绝执行它。

404 Not Found，请求失败，请求所希望得到的资源未被在服务器上发现。

5、服务器错误（5XX）:

500 Internal Server Error，服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器端的源代码出现错误时出现。

503 Service Unavailable，由于临时的服务器维护或者过载，服务器当前无法处理请求。

504 Gateway Timeout，作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

505 HTTP Version Not Supported，服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

HTTP方法

• GET，GET 用于从指定资源请求数据。
• POST，POST 用于将数据发送到服务器来创建/更新资源。

post请求几种常见content-type类型：

1. application/x-www-form-urlencoded：原生form表单
2. multipart/form-data：许多文件类型，比如文件
3. application/json：告诉服务端消息主体是JSON
4. text/xml：传输和存储数据
5. binary：二进制文件类型

• PUT，PUT 用于将数据发送到服务器来创建/更新资源。POST 和 PUT之间的区别在于 PUT 请求是幂等的（idempotent）。也就是说，多次调用相同的 PUT 请求将始终产生相同的结果。相反，重复调用POST请求具有多次创建相同资源的副作用。
• HEAD，HEAD 与 GET 几乎相同，但没有响应主体。换句话说，如果 GET /users 返回用户列表，那么 HEAD /users 将发出相同的请求，但不会返回用户列表。HEAD 请求对于在实际发出 GET 请求之前（例如在下载大文件或响应正文之前）检查 GET 请求将返回的内容很有用。
• DELETE，删除指定的资源。
• PATCH。
• OPTIONS，方法描述目标资源的通信选项。

粘包问题

​ 粘包指的是由于连续的数据传送，导致多个数据包混合在一起，没有办法有效的区分开。TCP是基于字节流的，只维护发送出去多少，确认了多少，并没有维护消息与消息之间的边界，因而极有可能导致粘包问题。

1、在发送端，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。

2、接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。

PS：UDP方案是不会出现粘包的，因为其有对应的数据分割。

一是对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满；

二是对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；

三是由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。

​

HTTPS

SSL加密算法

目的

1. 客户端与服务器需要就一组用于保护数据的算法达成一致；
2. 它们需要确立一组由那些算法所使用的加密密钥;
3. 握手还可以选择对客户端进行认证

加密过程

• 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器；
• 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数；
• 客户端对服务器的证书进行验证(有关验证证书，可以参考数字签名)，并抽取服务器的公用密钥；然后，再产生一个称作pre_master_secret的随机密码串，并使用服务器的公用密钥对其进行加密(参考非对称加/解密)，并将加密后的信息发送给服务器；
• 客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥(参考DH密钥交换算法)。
• 客户端将所有握手消息的MAC值发送给服务器；
• 服务器将所有握手消息的MAC值发送给客户端。

如何确保证书的可信度？

服务器证书需要验证域名所有权，OV/EV类型的证书还要验证企业信息，有效区别于假冒钓鱼网站，当然能让网站安全可信。

网络套接字
创建套接字，返回值就是套接字的文件描述符

视频理解

DH密钥交换算法：

现在假设Alice和Bob需要共享一个对称密码的密钥，然而双方之间的通信线路已经被窃听者窃听。这时，Alice和Bob可以通过下面的方法进行DH密钥交换，从而生成共享密钥。

1 Alice向Bob发送两个质数P和G

P必须是一个非常大的质数，而G则是一个和P相关的数，称为生成元。G可以是一个较小的数字。P和G不需要保密，被窃听者获取了也没关系。此外，P和G可以由Alice和Bob中的任意一方生成。

2 Alice生成一个随机数A

A是一个1~P-2之间的整数。这个数是一个只有Alice知道的秘密数字，没有必要告诉Bob，也不能让窃听者知道。

3 Bob生成一个随机数B

B是一个1~P-2之间的整数。这个数是一个只有Bob知道的秘密数字，没有必要高数Alice，也不能让窃听者知道。

4、Alice将 G的A次方 mod P 这个数发送给Bob

5、Bob 将 G的B次方 mod P 这个数发送给Alice

6、Alice用Bob发过来的数计算A次方并求 mod P

上面将mod P的“G的B次方的A次方” 改写成了“G的A*B次方”

7、Bob用Alice发过来的数计算B次方并求 mod P

上面将mod P的“G的A次方的B次方”改写成了“G的A*B次方”

于是Alice和Bob就计算出相等的共享密钥了。

HTTP/HTTPS的区别

1、HTTPS 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。

2、HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。

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

4、HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)