2022-05-06 22:55 已编辑门头沟学院 C++

关注

计算机网络

OSI七层参考模型

物理层：确保原始数据在各种物理媒体上的传输。
数据链路层：物理地址寻址、数据成帧、流量控制、数据的检错重发。
网络层：寻址、路由、拥塞控制、网际互连。
运输层：将上层数据进行分段并提供端到端的、可靠或不可靠的传输、差错控制、流量控制。
会话层：建立会话、如session认证、断点续传。
表示层：数据的解码和加密。
应用层：为操作系统或网络应用程序提供访问网络服务的接口。

名称	传输协议	传输单元	主要功能/接口
物理层	IEEE 802.1A 802.2	比特流	光纤、双绞线、中继器、集线器、网线接口
数据链路层	ARP、MAC、PPP	frame帧	网桥、二层交换机
网络层	IP、ICMP、ARP	packet数据包	路由器三层交换机
传输层	TCP、UDP	Segment/Datagram	四层交换机
会话层	SMTP、DNS	报文
表示层	Telnet、SNMP	报文
应用层	FTP、Telnet、HTTP、DNS	报文

TCP/IP参考模型

TCP/IP四层协议（数据链路层、网络层、传输层、应用层）

应用层应用层最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，TELNET等。
传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP UDP就是在这一层。端口号既是这里的“端”。
网络层本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。
数据链路层通过一些规程或协议来控制这些数据的传输，以保证被传输数据的正确性。实现这些规程或协议的硬件和软件加到物理线路，这样就构成了数据链路，

TCP三次握手

什么是TCP三次握手

在网络数据传输中，传输层协议TCP是要建立连接的可靠传输，TCP建立连接的过程，我们称为三次握手。

TCP三次握手的具体细节

第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；服务器确认了对方发送正常。
第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：自己接收正常，对方发送正常。
第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入 ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入 ESTABLISHED状态；完成三次握手，连接建立。客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：自己发送、接收正常，对方发送接收正常所以三次握手就能确认双发收发功能都正常，缺一不可。

简单来说就是：

客户端向服务端发送SYN
服务端返回SYN,ACK
客户端发送ACK

TCP超时重传

保证了数据的可靠传输，对于一些出错，丢包等问题TCP设计了超时与重传机制。
基本原理：在发送一个数据之后，就开启一个定时器，并设置RTO，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。
不同的网络情况不一样，不可能设置一样的RTO（超时重传时间），实际中RTO是根据网络中的RTT（报文段往返时间）来自适应调整的

建立连接可以两次握手么？

不可以。
因为可能会出现已失效的连接请求报文段又传到了服务器端。 > client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。
而且，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

可以采用四次握手吗？为什么？

这个肯定可以。三次握手都可以保证连接成功了，何况是四次，但是会降低传输的效率。

第三次握手中，如果客户端的ACK未送达服务器，会怎样？

Server端：由于Server没有收到ACK确认，因此会每隔 3秒重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。
Client端，会出现两种情况：
1. 在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态
2. 在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

TCP头部

源端口、目的端口：各占2字节。
序号SEQ：初始值随机ISN，之后会加上数据在整个数据流中的偏移量，解决网络包乱序问题。4个字节。
确认号ACK：收到的序号值+1即为响应。4字节。序号和确认号共同保证可靠性。
偏移量、保留区、标志位、窗口：定位数据、日后扩展、可混用的标志位、窗口大小保证稳定和流量控制，和接收方的缓冲区有关。
校验和、紧急指针：用循环冗余校验检查报文段是否有损坏、只向最后一个紧急数据的序号。
可选项、对齐填充：其中的MSS可控制TCP段的的大小和缓冲区大小有关。整体大小：20~60字节。

标志位	作用
URG	紧急指针是否有效
ACK	确认号是否有效
PSH	提示接收端立即从缓冲读走数据
RST	要求重新建立连接
SYN	请求建立连接
FIN	请求关闭一个连接

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

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

初始序列号是什么？

TCP连接的一方A，随机选择一个32位的序列号（Sequence Number）作为发送数据的初始序列号（Initial Sequence Number，ISN），比如为1000，以该序列号为原点，对要传送的数据进行编号：1001、1002...三次握手时，把这个初始序列号传送给另一方B，以便在传输数据时，B可以确认什么样的数据编号是合法的；同时在进行数据传输时，A还可以确认B收到的每一个字节，如果A收到了B的确认编号（acknowledge number）是2001，就说明编号为1001-2000的数据已经被B成功接受。

TCP的四次挥手

什么是TCP的四次挥手

在网络数据传输中，传输层协议断开连接的过程我们称为四次挥手
四次挥手断开连接是因为要确定数据全部传输完了

四次挥手的具体细节

第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态；客户要结束此次会话，就会对服务器说：我要关闭连接了。
第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。服务器收到客户的消息后说：好的，你要关闭连接了。
第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态；然后服务器确定了没有话要和客户说了，服务器就会对客户说，我要关闭连接了。
第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送一个 acknowledge number=序列号+1给服务器；服务器收到后，确认acknowledge number后，变为 CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入 CLOSED状态。完成四次挥手。客户收到服务器要结束连接的消息后说：已收到你要关闭连接的消息。(第四次挥手)，才关闭

为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态意义是什么）？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。

如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

客户端TIME_WAIT状态的意义是什么？

第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的 ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。 MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

什么是网络编程

网络编程的本质是多台计算机之间的数据交换。数据传递本身没有多大的难度，不就是把一个设备中的数据发送给其他设备，然后接受另外一个设备反馈的数据。现在的网络编程基本上都是基于请求/响应方式的，也就是一个设备发送请求数据给另外一个，然后接收另一个设备的反馈。在网络编程中，发起连接程序，也就是发送第一次请求的程序，被称作客户端(Client)，等待其他程序连接的程序被称作服务器(Server)。客户端程序可以在需要的时候启动，而服务器为了能够时刻相应连接，则需要一直启动。
例如以打电话为例，首先拨号的人类似于客户端，接听电话的人必须保持电话畅通类似于服务器。连接一旦建立以后，就客户端和服务器端就可以进行数据传递了，而且两者的身份是等价的。在一些程序中，程序既有客户端功能也有服务器端功能，最常见的软件就是QQ、微信这类软件了。

网络编程中两个主要问题

一个是如何准确的定位网络上一台或多台主机，
另一个就是找到主机后如何可靠高效的进行数据传输。

在TCP/IP协议中IP层主要负责网络主机的定位，数据传输的路由，由IP地址可以唯一地确定Internet上的一台主机。
而TCP层则提供面向应用的可靠（TCP）的或非可靠（UDP）的数据传输机制，这是网络编程的主要对象，一般不需要关心IP层是如何处理数据的。
目前较为流行的网络编程模型是客户机/服务器（C/S）结构。即通信双方一方作为服务器等待客户提出请求并予以响应。客户则在需要服务时向服务器提出申请。服务器一般作为守护进程始终运行，监听网络端口，一旦有客户请求，就会启动一个服务进程来响应该客户，同时自己继续监听服务端口，使后来的客户也能及时得到服务。

网络协议是什么

在计算机网络要做到井井有条的交换数据，就必须遵守一些事先约定好的规则，比如交换数据的格式、是否需要发送一个应答信息。这些规则被称为网络协议。

为什么要对网络协议分层

简化问题难度和复杂度。由于各层之间独立，我们可以分割大问题为小问题。
灵活性好。当其中一层的技术变化时，只要层间接口关系保持不变，其他层不受影响。
易于实现和维护。
促进标准化工作。分开后，每层功能可以相对简单地被描述

TCP / UDP

什么是TCP/IP和UDP

TCP/IP即传输控制/网络协议，是面向连接的协议，发送数据前要先建立连接(发送方和接收方的成对的两个之间必须建立连接)，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达.
UDP它是属于TCP/IP协议族中的一种。是无连接的协议，发送数据前不需要建立连接，是没有可靠性的协议。因为不需要建立连接所以可以在在网络上以任何可能的路径传输，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。

TCP与UDP区别：

TCP是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达；
UDP是无连接的协议，发送数据前不需要建立连接，是没有可靠性；
TCP通信类似于于要打个电话，接通了，确认身份后，才开始进行通行；
UDP通信类似于学校广播，靠着广播播报直接进行通信。
TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；
TCP是面向字节流的，UDP是面向报文的；面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。
TCP首部开销（20字节）比UDP首部开销（8字节）要大
UDP 的主机不需要维持复杂的连接状态表

TCP和UDP的应用场景：

对某些实时性要求比较高的情况使用UDP，比如游戏，媒体通信，实时直播，即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失的情况.

形容一下TCP和UDP

TCP通信可看作打电话
UDP通信可看为学校里的广播

运行在TCP 或UDP的应用层协议分析。

运行在TCP协议上的协议：

HTTP（Hypertext Transfer Protocol，超文本传输协议），主要用于普通浏览。
HTTPS（HTTP over SSL，安全超文本传输协议）,HTTP协议的安全版本。
FTP（File Transfer Protocol，文件传输协议），用于文件传输。
POP3（Post Office Protocol, version 3，邮局协议），收邮件用。
SMTP（Simple Mail Transfer Protocol，简单邮件传输协议），用来发送电子邮件。
TELNET（Teletype over the Network，网络电传），通过一个终端（terminal）登陆到网络。
SSH（Secure Shell，用于替代安全性差的TELNET），用于加密安全登陆用。

运行在UDP协议上的协议：

BOOTP（Boot Protocol，启动协议），应用于无盘设备。
NTP（Network Time Protocol，网络时间协议），用于网络同步。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置IP地址。

运行在TCP和UDP协议上：

DNS（Domain Name Service，域名服务），用于完成地址查找，邮件转发等工作。
ECHO（Echo Protocol，回绕协议），用于查错及测量应答时间（运行在TCP和UDP协议上）。
SNMP（Simple Network Management Protocol，简单网络管理协议），用于网络信息的收集和网络管理。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置IP地址。
ARP（Address Resolution Protocol，地址解析协议），用于动态解析以太网硬件的地址。

什么是ARP协议 (Address Resolution Protocol)？

ARP协议完成了IP地址与物理地址的映射。每一个主机都设有一个 ARP 高速缓存，里面有所在的局域网上的各主机和路由器的 IP 地址到硬件地址的映射表。当源主机要发送数据包到目的主机时，会先检查自己的ARP高速缓存中有没有目的主机的MAC地址，如果有，就直接将数据包发到这个MAC地址，如果没有，就向所在的局域网发起一个ARP请求的广播包（在发送自己的 ARP 请求时，同时会带上自己的 IP 地址到硬件地址的映射），收到请求的主机检查自己的IP地址和目的主机的IP地址是否一致，如果一致，则先保存源主机的映射到自己的ARP缓存，然后给源主机发送一个ARP响应数据包。源主机收到响应数据包之后，先添加目的主机的IP地址与MAC地址的映射，再进行数据传送。如果源主机一直没有收到响应，表示ARP查询失败。
如果所要找的主机和源主机不在同一个局域网上，那么就要通过 ARP 找到一个位于本局域网上的某个路由器的硬件地址，然后把分组发送给这个路由器，让这个路由器把分组转发给下一个网络。剩下的工作就由下一个网络来做。
ARP请求应答报文的长度是28字节
主机向自己所在的网络广播一个ARP请求，该请求包含目标机器的网络地址。此网络上的其他机器都将收到这个请求，但是只有被请求的目标机器会回应一个ARP应答，其中包含自己的物理地址。

什么是NAT (Network Address Translation, 网络地址转换)？

用于解决内网中的主机要和因特网上的主机通信。由NAT路由器将主机的本地IP地址转换为全球IP地址，分为静态转换（转换得到的全球IP地址固定不变）和动态NAT转换。

从输入址到获得页面的过程?

浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

ping发生了什么

ping主要是为了测试两台主机之间的连通性，通过应用层直接使用网络层ICMP，没有通过运输层TCP和UDP，是通过发送ICMP报文回显请求实现。

A主机构建一个ICMP格式的数据包，通过ICMP协议把该数据包和B主机的IP地址一起交给IP协议；

IP层构建一个数据包（A主机的IP地址+控制信息+B主机的IP地址），获得B主机的MAC地址，以便构建一个数据帧(IP协议会根据B主机的IP地址和自己的子网掩码判断是不是属于同一层网络,如果是属于同一层网络的话,就会获得B主机的MAC地址，如果以前两机有过通信，在A机的ARP缓存表应该有B机IP与其MAC的映射关系，如果没有，就发一个ARP请求广播，得到B机的MAC)

主机B接受到主机A的发过来的数据帧以后，先检查该帧中包含的B的IP地址，并和本地的物理地址进行比对，如果符合的话，就接受，否则，就抛弃。同样，需要将该数据帧交由自己的IP层协议，IP层检查以后，再交由ICMP协议，构建一个ICMP的应答包，发送给主机A。

traceroute发生了什么

traceroute用来跟踪一个分组从源点到终点的路径，及到达其中每一个路由器的往返时间

通过发送UDP报文，设置目的端口为一个不可能的值
将IP首部中的TTL分别设置从1到N，每次逐个增加
每次设置TTL后，重新发送数据报，路由器接收到数据报后，将TTL减1，若当前的路由器接收到数据报，发现TTL为1时，会将TTL减1变为0，然后丢弃数据报，发送ICMP时间超过报文
如果最后一个数据报刚刚达到主机，数据报的TTL是1，此时主机不把TTL减1
因IP数据报中封装的是无法交付的UDP数据报，此时目的主机向源主机发送ICMP终点不可达差错报文，表示达到目的主机

拥塞控制和流量控制的区别

拥塞控制是防止过多的数据注入到网络中，可以使网络中的路由器或链路不致过载，是一个全局性的过程。
流量控制是点对点通信量的控制，是一个端到端的问题，主要就是抑制发送端发送数据的速率，以便接收端来得及接收

TCP滑动窗口实现流量控制

流量控制是让发送方的发送速率不要太快，要让接收方来得及接收，实现对发送方的流量控制.
滑动窗口出现的原因：在确认应答策略中，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点，就是性能比较差，尤其是数据往返的时间长的时候
滑动窗口以字节为单位，而不是报文

域名系统DNS

用于将域名转换为IP地址。DNS解析过程有两种，分别是递归查询和迭代查询。

递归查询
- 若主机询问的本地域名服务器不知道被查询域名的IP地址，本地域名服务器以DNS客户身份，向其他根域名服务器继续发出查询请求报文（代替该主机继续查询），而不是该主机自己进行下一步查询
迭代查询
- 当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出IP地址，要么告诉本地域名服务器，应该向哪一个域名服务器进行查询，然后本地域名服务器进行后续查询。

HTTP

概述

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web）服务器传输超文本到本地浏览器的传送协议。
HTTP属于应用层协议，基于TCP/IP通信协议来传递数据

特点

灵活
- HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
无连接
- 无连接的含义是通信双方在交换HTTP报文之前不需要建立HTTP连接
无状态
- 无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时应答较快。
支持B/S和C/S模式
默认端口80
基于TCP协议

HTTP工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。

客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。
服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP 请求/响应的步骤

客户端连接到Web服务器 一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。

发送HTTP请求 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

服务器接受请求并返回HTTP响应 Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

释放连接TCP连接 若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;

客户端浏览器解析HTML内容 客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

HTTP2

新的二进制格式（Binary Format）
- HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用（MultiPlexing）
- 即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
- pipelining在接收response返回时，必须依顺序接收，如果前一个请求遇到了阻塞，后面的请求即使已经处理完毕了，仍然需要等待阻塞的请求处理完毕。这种情况就如图中第三种，第一个请求阻塞后，后面的请求都需要等待，这也就是队头阻塞
header压缩
- 对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小
服务端推送
- 我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了

HTTP持久连接与管线化

HTTP协议首先要和服务器建立TCP连接，这需要三次握手。

请求一个万维网文档的时间
- 当建立TCP连接的三次握手前两次完成后，即经过一个RTT时间，万维网客户就把HTTP请求报文，作为建立TCP连接的三次握手中的第三次的数据，发送给万维网服务器，服务器收到HTTP请求后，把请求的文档作为响应报文返回给客户。
- 文档传输时间+2*RTT
HTTP1.0非持久连接的缺点
- 每请求一个文档，需要两倍RTT的开销。服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接，然后重新建立连接发出请求
HTTP1.1持久连接
- 万维网服务器在发送响应后仍然在一段时间内保持这段连接，可以使得同一用户继续在该连接上传送后续请求和响应报文
持久连接的两种工作方式
- 非管线化
  - 发送请求后需等待并收到回应，才能发送下一个请求
- 管线化
  - 不用等待响应，直接发送下一个请求，但接收的时候必须按照顺序接收，如果有一个请求阻塞，则接收会全部阻塞

HTTP协议请求报文具体信息

HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据四个部分组成

GET

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host:img.mukewang.com
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept:image/webp,image/*,*/*;q=0.8
Referer:http://www.imooc.com/
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8
空行
请求数据为空

POST

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
空行
name=Professional%20Ajax&publisher=Wiley

请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本. GET说明请求类型为GET，/562f25980001b1b106000338.jpg(URL)为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。

请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息

HOST，给出请求资源所在服务器的域名.

User-Agent，HTTP客户端程序的信息，该信息由你发出请求使用的浏览器来定义,并且在每个请求中自动发送等

Accept，说明用户代理可处理的媒体类型

Accept-Encoding，说明用户代理支持的内容编码

Accept-Language，说明用户代理能够处理的自然语言集

Content-Type，说明实现主体的媒体类型

Content-Length，说明实现主体的大小

Connection，连接管理，可以是Keep-Alive或close

空行，请求头部后面的空行是必须的即使第四部分的请求数据为空，也必须有空行。

请求数据也叫主体，可以添加任意的其他数据。

GET和POST区别

GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive
空行
请求数据为空

区别
- get参数通过url传递，post放在request body中，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变
- POST的安全性要比GET的安全性高，一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码.
- get请求在url中传递的参数是有长度限制的，而post没有
- GET产生一个TCP数据包，POST产生两个TCP数据包。
  - 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
  - 对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

HTTP状态码

1xx：指示信息--表示请求已接收，继续处理。
2xx：成功--表示请求正常处理完毕。
- 200 OK：客户端请求被正常处理
- 206 Partial content：客户端进行了范围请求
3xx：重定向--要完成请求必须进行更进一步的操作。
- 301 Moved Permanently：永久重定向，该资源已被永久移动到新位置，将来任何对该资源的访问都要使用本响应返回的若干个URI之一
- 302 Found：临时重定向，请求的资源现在临时从不同的URI中获得
4xx：客户端错误--请求有语法错误，服务器无法处理请求。
- 400 Bad Request：请求报文存在语法错误
- 403 Forbidden：请求被服务器拒绝
- 404 Not Found：请求不存在，服务器上找不到请求的资源
5xx：服务器端错误--服务器处理请求出错。
- 500 Internal Server Error：服务器在执行请求时出现错误
- 503 Service Unavaliable：服务器正在停机维护

IP/TCP/UDP分片

数据发送时，将数据从应用层->传输层->网络层->数据链路层，其中传输层是TCP和UDP，网络层是IP协议。

MTU以太网帧的长度为1500字节，所能接收的传输层数据段最大为 1480 个字节（以太网帧中的数据包括 IP 协议的报头信息，IP 协议的报头信息为 20 字节）
在计算 MSS （网络传输数据最大值）的时候，用 MTU 减去网络层报头长度以及传输层报头长度即可。
UDP
- 一旦 UDP 携带的数据超过了 1472 （MTU - IP报头 - UDP报头 = 1500 - 20 - 8），那么在 IP 层就会对该数据分片，一旦分片就意味着增加了 UDP 传输丢包的可能性。由于 UDP 协议传输本身就不负责可靠性，再加上分片，那么丢包的可能性就大大增加。

数字签名和数字证书

使用公钥密码加密的一般流程：通过A的公钥对报文加密，发送给B，然后B拿A的私钥进行解密，得到报文. 注意：并不是每次传输报文的时候都要加数字签名，数字签名一般用于数字证书的验证，这样的话浏览器内置的CA拥有服务端的公钥和私钥。

数字签名
- 普通数字签名(能核实发送者，但无法保证报文完整性)
  - A通过A的私钥对报文进行加密，将其附在报文的后面，发送给B，然后B拿A的公钥对附加信息进行解密的过程，为数字签名
  - 上述过程中仅仅实现了数字签名，但并没有对实际报文进行加密。实际操作时，可以通过A-->A私钥(数字签名)-->B公钥(报文加密)-->B私钥(报文解密)-->A公钥(验证数字签名)
- 密码散列函数
  - 使用密码散列函数对报文进行与运算得到hash值，简称摘要
  - 密码散列函数有MD5和安全散列算法SHA
- 报文摘要数字签名(核实发送者，保证报文完整性) 对报文本身加密可能是个耗时过程，比如这封Email足够大，那么私钥加密整个文件以及拿到文件后的解密无疑是巨大的开销
  - A先对这封Email执行哈希运算得到hash值简称“摘要”，取名h1
  - 然后用自己私钥对摘要加密，生成的东西叫“数字签名”
  - 把数字签名加在Email正文后面，一起发送给B
  - 防止邮件被窃听你可以用继续B公钥加密
  - B收到邮件后使用B私钥对报文解密，用A的公钥对数字签名解密，成功则代表Email确实来自A，失败说明有人冒充
  - B对邮件正文执行哈希运算得到hash值，取名h2
  - B会对比数字签名的hash值h1和自己运算得到的h2，一致则说明邮件未被篡改。
- 数字签名的作用
  - 确认核实发送者
  - 保证报文的完整性
  - 一般用于验证数字证书
数字证书明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了，由认证中心（CA）或者认证中心的下级认证中心颁发。通俗来说，A确认收到的公钥真的是B的公钥，而不是别人伪造的
- 制作数字签名
  - CA拥有非对称加密的私钥和公钥。
  - CA对证书明文信息进行hash。
  - 对hash后的值用私钥加密，得到数字签名
  - 明文和数字签名共同组成了数字证书
- 数字证书验证过程
  - 拿到证书，得到明文T，数字签名S。
  - 用CA机构的公钥对S解密，得到S’。（由于是浏览器信任的机构，浏览器保有它的公钥，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥）
  - 用证书里说明的hash算法对明文T进行hash得到T’。
  - 比较S’是否等于T’，等于则表明证书可信。

HTTP和HTTPS的区别

HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS加密后的，HTTPS具有更高的安全性

HTTPS可以保证报文完整性，另外可以核实发送者身份

HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书

HTTPS在TCP三次握手阶段之后，还需要进行SSL的handshake，协商加密使用的对称加密密钥

HTTP协议端口是80，HTTPS协议端口是443

运输层安全协议及SSL工作过程

alt

SSL 安全套接字层协议
TLS 运输层安全协议，在SSL的基础上设计
SSL工作过程
- 协商加密算法
  - 浏览器A向服务器B发送SSL版本，及自身支持的加密组件（包括加密算法及密钥长度等）
  - B从中选择自身支持的加密组件和SSL版本，发送给A
- 服务器鉴别
  - B向A发送包含公开密钥的数字证书
  - A对数字证书进行鉴别，获取B的公钥
- 会话密钥计算
  - A随机产生秘密数，将秘密数通过B的公钥发送给B，之后A通过协商的加密算法产生会话密钥
  - B接收到秘密数后，通过B的私钥将其解密得到秘密数，然后根据协商加密算法产生会话密钥
- 安全数据传输
  - 双方会互相发送一次数据，用会话密钥加密和解密他们之间传达的数据并验证其完整性
- 通信
  - 上述验证通过后，才继续进行http通信

HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？

显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？用session就行。

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下
之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

cookie和session

HTTP协议作为无状态协议，对于HTTP协议而言，无状态指每次request请求之前是相互独立的，当前请求并不会记录它的上一次请求信息，如何将上下文请求进行关联呢？客户端（不同的浏览器）记录用户的状态通过cookie，服务器端（不同的网站）记录用户的状态通过session。

cookie

工作流程

客户端请求服务器端，服务器端产生cookie响应头，随响应报文发送给客户端，客户端将cookie文本保存起来
下次客户端再次请求服务端时，会产生cookie请求头，将之前服务器发送的cookie信息，再发送给服务器，服务器就可以根据cookie信息跟踪客户端的状态。

基础知识

Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie，它是服务器端存放在本地机器中的数据，随每一个请求发送给服务器，由于Cookie在客户端，所以可以编辑伪造，不是十分安全。

非持久cookie
- 内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。
持久cookie
- 硬盘Cookie保存在硬盘里，有一个过期时间（客户端cookie设置的时间），除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。

session

工作流程

当用户第一次访问站点时，服务器端为用户创建一个sessionID，这就是针对这个用户的唯一标识，每一个访问的用户都会得到一个自己独有的session ID，这个session ID会存放在响应头里的cookie中，之后发送给客户端。这样客户端就会拥有一个该站点给他的session ID。
当用户第二次访问该站点时，浏览器会带着本地存放的cookie(里面存有上次得到的session ID)随着请求一起发送到服务器，服务端接到请求后会检测是否有session ID，如果有就会找到响应的session文件，把其中的信息读取出来；如果没有就跟第一次一样再创建个新的。

基础知识

session是存放在服务器里的，所以session 里的东西不断增加会增加服务器的负担，我们会把一些重要的东西放在session里，不太重要的放在客户端cookie里

session失效
- 服务器（非正常）关闭时
- session过期/失效（默认30分钟）
  - 问题：时间的起算点从何时开始计算30分钟？从不操作服务器端的资源开始计时（例如：当你访问淘宝页面时，点开页面不动，第29分钟再动一下页面，就得重新计时30分钟；当过了30分钟，就失效了。）
- 手动销毁session
sessionID的传递方式
- 通过cookie传递
- 当cookie禁用后，可以通过url传递
不同场景下的session
- 当在同一个浏览器中同时打开多个标签，发送同一个请求或不同的请求，仍是同一个session;
- 当不在同一个窗口中打开相同的浏览器时（打开多个相同的浏览器），发送请求，仍是同一个session;
- 当使用不同的浏览器时，发送请求，即使发送相同的请求，是不同的session;
- 当把当前某个浏览器的窗口全关闭，再打开，发起相同的请求时，是不同的session。

区别

cookie数据存放在客户的浏览器上，session数据放在服务器上。
cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
可以考虑将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中。

浏览器关闭后，session就销毁了吗

浏览器关闭和服务器session销毁没有任何关系，会话Cookie（非持久cookie）在关闭浏览器后就会消失，但是原来服务器的Session还在，只有等到了销毁的时间会自动销毁。

UDP怎么实现可靠传输

QUIC：Quick UDP Internet Connection

自定义的连接机制一次往返就可以建立连接，在应用层实现，只要ip变化id不变就不需要重新连接。
解决队头阻塞
自定义流量控制
改进的拥塞控制 TCP存在的问题： 1、TCP存在队头阻塞导致资源传输停止问题。 2、三次握手和四次挥手耗时。 3、TCP是OS内核级别实现，难以更改。而UDP虽然更加快速，但是不像TCP一样可以保证可靠传输。要从udp协议层面保证可靠传输，就要修改os，链路或者路由器节点，很复杂并且难以推过，因此可以从应用层接收到udp报文之后做可靠传输控制。 QUIC（quick udp internet connection）协议的目的是整合TCP的可靠性和UDP的效率和灵活性。特点在于 1、自定义的连接机制：不需要三次握手，一次数据的往返就可以建立首次连接，客户端随机产生一个64位的随机数作为链接标识，当网络出现中断，只要链接标识不改变，链接就不会中断，在频繁切换网络或者进入地铁电梯的场景，相对于三次握手，效率很高。 2、解决队头阻塞问题：TCP由于保证时序的，所以某个资源的某个包丢失了，就会在接收端队头形成阻塞，只有该包恢复，资源才会重新传输。QUIC是基于UDP的，UDP特点是不保证包的时序，发出去就不管了，因此不会形成队头阻塞问题。 3、自定义的流量控制和拥塞控制：直接在应用层实现，可以根据不同的程序做更细粒度的配置管理。

ICMP协议（Internet Control Message Protocol）

是IP协议的重要补充，主要用于检测网络连接。

报文格式：8位类型字段（差错/查询） + 8位代码字段（细分不同的条件） + 16位校验和 + 报文内容

ping就是利用ICMP报文检测网络连接，是调试网络设备的工具。ping是一个应用程序而不是协议。

IP协议

IP头部信息用于指定通信的源端IP地址、目的端IP地址，指导IP分片和重组
IP数据报的路由和转发
IP协议是无状态的。接收端的IP模块只要收到了完整的IP数据报（如果IP分片的话要先重组），就将其数据部分上交给上层协议。
IP数据报头部的标识字段用以标识唯一的IP数据报，它是用来处理IP分片和重组的。

IPv4协议

IPv4头部字段一般20个字节，包括版本号，总长度，标识位（相同标识位代表同一个IP数据报）、分片偏移，校验和，生存时间（TTL）
IP分片：当IP数据报的长度超过帧的MTU（以太网默认1500）时，它将被分片传输。分片可能发生在发送端，也可能发生在中转路由器上，只有在最终的目标机器上这些分片会在内核中的IP模块重新组装。
IP模块接收来自数据链路层的数据之后先进行CRC校验。转发子模块判断是广播还是发给自己。
IP路由：IP数据报应该发送至哪个下一跳的路由（或者目标机器）以及经过哪个网卡来发送。