网络协议（TCP/IP、HTTP、HTTPS）

网络

什么是网络编程

网络编程的本质是多台计算机之间的数据交换。数据传递本身没有多大的难度，不就是把一个设备中的数据发送给其他设备，然后接受另外一个设备反馈的数据。现在的网络编程基本上都是基于请求/响应方式的，也就是一个设备发送请求数据给另外一个，然后接收另一个设备的反馈。在网络编程中，发起连接程序，也就是发送第一次请求的程序，被称作客户端(Client)，等待其他程序连接的程序被称作服务器(Server)。客户端程序可以在需要的时候启动，而服务器为了能够时刻相应连接，则需要一直启动。

网络编程中两个主要的问题

一个是如何准确的定位网络上一台或多台主机，

另一个就是找到主机后如何可靠高效的进行数据传输。

在TCP/IP协议中IP层主要负责网络主机的定位，数据传输的路由，由IP地址可以唯一地确定Internet上的一台主机。
而TCP层则提供面向应用的可靠（TCP）的或非可靠（UDP）的数据传输机制，这是网络编程的主要对象，一般不需要关心IP层是如何处理数据的。

目前较为流行的网络编程模型是客户机/服务器（C/S）结构。即通信双方一方作为服务器等待客户提出请求并予以响应。客户则在需要服务时向服务器提出申请。服务器一般作为守护进程始终运行，监听网络端口，一旦有客户请求，就会启动一个服务进程来响应该客户，同时自己继续监听服务端口，使后来的客户也能及时得到服务。

网络协议是什么

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

为什么要对网络协议分层

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

计算机网络体系结构

OSI定义了网络互连的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）

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

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

TCP

TCP报头 什么是TCP/IP和UDP

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

TCP和UDP的⽐较

TCP向上层提供⾯向连接的可靠服务，UDP向上层提供⽆连接不可靠服务。虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求⾼的地⽅有所作为对数据准确性要求⾼，速度可以相对较慢的，可以选⽤TCP

面向连接和非面向连接的服务的特点是什么？

面向连接的服务，通信双方在进行通信之前，要先在双方建立起一个完整的可以彼此沟通的通道，在通信过程中，整个连接的情况一直可以被实时地监控和管理。

非面向连接的服务，不需要预先建立一个联络两个通信节点的连接，需要通信的时候，发送节点就可以往网络上发送信息，让信息自主地在网络上去传，一般在传输的过程中不再加以监控。

TCP和UDP的应用场景： TCP通信可看作打电话-----UDP通信可看为学校里的广播

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

运行在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 找到一个位于本局域网上的某个路由器的硬件地址，然后把分组发送给这个路由器，让这个路由器把分组转发给下一个网络。剩下的工作就由下一个网络来做。

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

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

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

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

TCP三次握⼿

为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。

IP 是位于网络层的无连接的通讯协议，IP 协议只负责将 IP 包送往发送给目的地，但不确保发送到目的地，所以在传输层采用有连接的方式，来确保数据的送达。

简单来说就是：

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

第一次握手：建立连接时，客户端发送 syn（Synchronize Sequence Numbers：同步序列编号）包（seq=x）到服务器，并进入SYN_SEND（请求连接）状态，等待服务器确认。
第二次握手：服务器接收到 syn包，必须确认客户的 SYN（ack=x+1）（ack：确认字符，表示发来的数据已确认接收无误），同时自己也发送一个 syn包（seq=y），既 SYN+ACK 包，此时服务器进入SYN_RECV（发送了ACK）状态。
第三次握手：客户端收到服务端发送的 SYN+ACK 包，向服务端发送确认包 ACK（ack=y+1），包发送完毕，客户端与服务器进入 ESTABLISHED（TCP连接成功）状态，完成三次握手。

为什么要进⾏第三次握⼿

为了防⽌服务器端开启⼀些⽆⽤的连接增加服务器开销以及防⽌已失效的连接请求报⽂段突然⼜传送到了服务端

因为可能会出现已失效的连接请求报文段又传到了服务器端。 > 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端，会出现两种情况：

在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态
在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

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

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为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连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。

（1）：客户端发送终⽌命令FIN，用来关闭客户端到服务端的数据传送，也就是客户端告诉服务端,但是，此时客户端还可以接受数据。

（2）：服务端收到FIN包后,服务端收到后回复ACK，处于close_wait状态

（3）：服务端发送一个FIN，用来关闭服务端到客户端的数据传送,服务器将关闭前需要发送信息发送给客户端后处于last_ack状态

（4）：客户端收到FIN后，发送一个ACK给服务端,客户端收到FIN后发送ack后处于tim-wait⽽后进⼊close状态

断开连接如果只有两次挥手，会出现什么

由于TCP连接是双向的，因此每个方向都需要单独进行关闭。原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一个方向上没有数据流动，一个 TCP连接到一个 FIN后仍能发送数据。首次执行FIN的一方主动关闭，另一方则执行被动关闭。当只握手两次时，就只会关闭主动发起的一端，另一个仍能发送数据。

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

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

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

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

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

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

安全问题
首次握手 ------ SYN 超时

在 Server 收到 Client 的 SYN 之后，回复 SYN-ACK 的时候未收到 ACK 确认，导致服务端不断重试，直到超时。

SYN Flood 攻击

恶意程序会在短时间对服务器不断发起建立连接请求，但不响应服务器请求，导致服务器不断重发，占用资源，导致崩溃。

应对 SYN Flood 攻击的方式

SYN 队列满后，通过 tcp_syncookies 参数回发 SYN Cookie
若为正常连接，则 Client 会回发 SYN Cookie，建立连接

建立连接后，Client 故障---------保活机制

向 Client 发送探测报文，如果未收到响应则继续发送，直到收到响应或达到保活探测数时，中断连接。

为什么客户端发送完最后一个 ACK 包之后还需要 TIME-WAIT

确保有足够的时间让对方接收到 ACK 包
避免新旧连接混淆

服务器出现大量 CLOSE-WAIT 状态的原因

客户端关闭 socket 连接，服务端忙于处理读或写，没有及时关闭连接

检查代码，特别是资源释放代码
检查配置，特别是处理请求的线程配置

Socket

什么是Socket

网络上的两个程序通过一个双向的通讯连接实现数据的交换，这个双向链路的一端称为一个Socket。Socket通常用来实现客户方和服务方的连接。Socket是TCP/IP协议的一个十分流行的编程界面，一个Socket由一个IP地址和一个端口号唯一确定。

但是，Socket所支持的协议种类也不光TCP/IP、UDP，因此两者之间是没有必然联系的。在Java环境下，Socket编程主要是指基于TCP/IP协议的网络编程。

socket连接就是所谓的长连接，客户端和服务器需要互相连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉的，但是有时候网络波动还是有可能的

Socket偏向于底层。一般很少直接使用Socket来编程，框架底层使用Socket比较多，

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个外观模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议

Socket通讯的过程

基于TCP：服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。

基于UDP：UDP 协议是用户数据报协议的简称，也用于网络数据的传输。虽然 UDP 协议是一种不太可靠的协议，但有时在需要较快地接收数据并且可以忍受较小错误的情况下，UDP 就会表现出更大的优势。我客户端只需要发送，服务端能不能接收的到我不管

TCP 粘包和拆包产生的原因

TCP虽然是可靠面向连接的协议，网络编程时客户端和服务端都要有一一成对的socket。

但TCP是个"流"协议，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题
图解

1）服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包；

（2）服务端一次接收到了两个数据包，D1和D2粘合在一起，被称为TCP粘包；

（3）服务端分两次读取到了两个数据包，第一次读取到了完整的D1包和D2包的部分内容，第二次读取到了D2包的剩余内容，这被称为TCP拆包；

（4）服务端分两次读取到了两个数据包，第一次读取到了D1包的部分内容D1_1，第二次读取到了D1包的剩余内容D1_2和D2包的整包。

原因：

（1）要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包；

（2）接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包；

（3）要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包；

（4）待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。

解决办法： 关键是服务器端每次读取数据长度的问题（自定义协议+编解码器）

消息定长。发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
设置消息边界。服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如FTP协议。
将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段。
更复杂的应用层协议。

TCP/IP 如何保证可靠性

1）、三次握手。

2）、将数据截断为合理的长度。应用数据被分割成 TCP 认为最合适发送的数据块。

3）、超时重发。

4）、对于收到的请求，给予确认响应。

5）、如果校验出数据包有错，则丢弃报文段，不响应。

6）、对失序数据进行重新排序，发送于客户端。

7）、能够丢弃重复数据。

8）、流量控制。TCP连接的两端都有缓存大小控制，接收端只允许发送端发送自己缓存剩余大小的数据。有效防止缓存溢出。

9）、拥塞控制。当网络阻塞时，减少数据的发送。

HTTP

Http协议是对客户端和服务器端之间数据之间实现可靠性的传输文字、图片、音频、视频等超文本数据的规范，格式简称为"超文本传输协议"

Http协议属于应用层，及用户访问的第一层就是http

Socket和http的区别和应用场景

Socket连接就是所谓的长连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉；
Socket适用场景：网络游戏，银行持续交互，直播，在线视屏等。
http连接就是所谓的短连接，即客户端向服务器端发送一次请求，服务器端响应后连接即会断开等待下次连接

http适用场景：公司OA服务，互联网服务，电商，办公，网站等等等等

什么是http的请求体？

HTTP请求体是我们请求数据时先发送给服务器的数据，毕竟我向服务器那数据，先要表明我要什么吧
HTTP请求体由：请求行、请求头、请求数据组成的，

注意：GIT请求是没有请求体的

POST请求
GIT请求是没有请求体的

http的响应报文有哪些？

http的响应报是服务器返回给我们的数据，必须先有请求体再有响应报文
响应报文包含三部分状态行、响应首部字段、响应内容实体实现

http和https的区别？

其实HTTPS就是从HTTP加上加密处理（一般是SSL安全通信线路）+认证+完整性保护

区别：

http需要拿到ca证书，需要钱的
端口不一样，http是80，https443
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式（http的连接很简单，是无状态的；HTTPS 协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。）

一次完整的HTTP请求所经历几个步骤?

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

建立TCP连接

怎么建立连接的，看上面的三次捂手
Web浏览器向Web服务器发送请求行

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。
Web浏览器发送请求头

浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
Web服务器应答

客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
Web服务器发送应答头

正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
Web服务器向浏览器发送数据

Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
Web服务器关闭TCP连接

常用HTTP状态码是怎么分类的，有哪些常见的状态码？

HTTP状态码表示客户端HTTP请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。

状态码的类别：

1xx：指示信息--表示请求已接收，正在处理

2xx：成功--表示请求已被成功接收、理解、接受

3xx：重定向--要完成请求必须进行更进一步的操作

4xx：客户端错误--请求有语法错误或请求无法实现

5xx：服务器端错误--服务器未能实现合法的请求

常见的状态码：

200：请求被正常处理

204：请求被受理但没有资源可以返回

206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。

301：永久性重定向

302：临时重定向

303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上

304：发送附带条件的请求时，条件不满足时返回，与重定向无关

307：临时重定向，与302类似，只是强制要求使用POST方法

400：请求报文语法有误，服务器无法识别

401：请求需要认证

403：请求的对应资源禁止被访问

404：服务器无法找到对应资源

500：服务器内部错误

503：服务器正忙

Http协议中有那些请求方式

GET：用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器

POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。

PUT：传输文件，报文主体中包含文件内容，保存到对应URI位置。

HEAD：获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。

PATCH：客户端向服务器传送的数据取代指定的文档的内容(部分取代)

TRACE：回显客户端请求服务器的原始请求报文，用于"回环"诊断

DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。

OPTIONS：查询相应URI支持的HTTP方法。

GET方法与POST方法的区别

区别一：get重点在从服务器上获取资源，post重点在向服务器发送数据；
区别二：Get传输的数据量小，因为受URL长度限制，但效率较高；Post可以传输大量数据，所以上传文件时只能用Post方式；
区别三：get是不安全的，因为get请求发送数据是在URL上，是可见的，可能会泄露私密信息，如密码等；post是放在请求头部的，是安全的

http版本的对比

HTTP1.0版本的特性：

早先1.0的HTTP版本，是一种无状态、无连接的应用层协议。

HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

HTTP1.1版本新特性

1默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求

2管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应

3断点续传原理

HTTP2.0版本的特性

二进制分帧（采用二进制格式的编码将其封装）

首部压缩（设置了专门的首部压缩设计的HPACK算法。）

流量控制（设置了接收某个数据流的多少字节一些流量控制）

多路复用（可以在共享TCP链接的基础上同时发送请求和响应）

请求优先级（可以通过优化这些帧的交错和传输顺序进一步优化性能）

服务器推送（就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。（重大更新））

如何理解HTTP协议的无状态性

HTTP协议是无状态的，指的是HTTP协议对于事务处理没有记忆功能，服务器不知道客户端是什么状态。相当于，打开一个服务器上的网页与上一次打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不代表HTTP使用的是UDP协议（无连接）。

cookie和session对于HTTP有什么用？

HTTP协议本身是无法判断用户身份。所以需要cookie或者session

什么是cookie

cookie是由Web服务器保存在用户浏览器上的文件（key-value格式），可以包含用户相关的信息。客户端向服务器发起请求，就提取浏览器中的用户信息由http发送给服务器

什么是session

session 是浏览器和服务器会话过程中，服务器会分配的一块储存空间给session。

服务器默认为客户浏览器的cookie中设置 sessionid，这个sessionid就和cookie对应，浏览器在向服务器请求过程中传输的cookie 包含 sessionid ，服务器根据传输cookie 中的 sessionid 获取出会话中存储的信息，然后确定会话的身份信息。

cookie与session区别

cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对更高单个cookie保存的数据不能超过4K，session无此限制信息后，使用自己的私钥进行解密。由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，非常的慢

HTTP 的长连接是什么意思

长连接是指客户端与服务端建立连接后，不会因完成了一次请求后，它们之间的连接主动关闭。后续的读写操作会继续使用这个链接。如果一个连接两小时内都没有任何动作，服务器会向客户端发送一个探测报文段、根据客户端主机相应探测4个客户端状态，①、客户端正常时，且服务器可达。此时客户端TCP响应正常，服务器将定时器复位。②、客户端已经崩溃，并且关闭或正在重启，客户端不能响应TCP，服务器将无法收到客户端对探测器的响应。服务器总共发送10个这样的探测，每间隔75秒。如服务器没有收到任何响应，他就认为客户端已经关闭并终止连接。③、客户端崩溃，但已重启。服务器将对其保持探测响应，这个响应是一个复位，使得服务器终止这个连接。④、客户机正常运行，但是服务器不可达。这种与②类似

HTTPS=HTTP+加密+认证+完整性保护

HTTPS并非是应用层的一种新协议，只是HTTP通信接口部分用SSL和TLS协议代替而已。通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。其实HTTPS就是身披SSL协议外壳的HTTP。

采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。

Https 的三次握手

HTTPS工作原理

一、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；

二、客户端如果校验通过后，就根据证书的公钥的有效，生成随机数，随机数使用公钥进行加密（RSA加密）；

三、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；

四、发送给服务端，此时只有服务端（RSA私钥）能解密。

五、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

1.解决内容可能被窃听的问题------加密

方法1.对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。

以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

方法2.非对称加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。640?wx_fmt=png

非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

这种方式有以下缺点：

公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；
公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；
使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；

方法3.对称加密+非对称加密(HTTPS采用这种方式)

使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就比如说你抢到了一个保险柜，但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

具体做法是：发送密文的一方使用对方的公钥进行加密处理"对称的密钥"，然后对方用自己的私钥解密拿到"对称的密钥"，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

2.解决报文可能遭篡改问题------数字签名

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？----校验数字签名。

数字签名有两种功效：

能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名如何生成:
将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。

校验数字签名流程：
接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

假设消息传递在Kobe，James两人之间发生。James将消息连同数字签名一起发送给Kobe，Kobe接收到消息后，通过校验数字签名，就可以验证接收到的消息就是James发送的。当然，这个过程的前提是Kobe知道James的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Kobe,或者说拿到的公钥如何证明是James的。

此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，Kobe客户端内置了所有受信任CA的证书。CA对James的公钥（和其他信息）数字签名后生成证书。

3.解决通信方身份可能被伪装的问题------数字证书

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上

我们来介绍一下数字证书认证机构的业务流程：

服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

数据完整性验证

数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改，或者数据比特被污染，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性（由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性）。 MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的作用下，利用MAC算法计算出消息的MAC值，并将其添加在需要发送的消息之后，并发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改或者污染，接收者将丢弃该报文。 SHA也不能使用SHA0和SHA1，山东大学的王小云教授（很牛的一个女教授，大家有兴趣可以上网搜索一下她的事迹）在2005年就宣布破解了 SHA-1完整版算法，并获得了业内专家的认可。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。

HTTPS的优点

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

（4）谷歌曾在2014年8月份调整搜索引擎算法，并称"比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高"。

HTTPS的缺点

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

DNS使用的协议（既使用 TCP 也使用 UDP）

【1】首先了解一下 TCP与 UDP传送字节的长度限制：UDP报文的最大长度为 512字节，而 TCP则允许报文长度超过 512字节。当 DNS查询超过 512字节时，协议的 TC标志出现删除标志，这时则使用 TCP发送。通常传统的 UDP报文一般不会大于512字节。

【2】区域传送时使用TCP，主要有一下两点考虑：辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用 TCP而不是 UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。TCP是一种可靠的连接，保证了数据的准确性。

【3】域名解析时使用 UDP 协议：客户端向 DNS 服务器查询域名，一般返回的内容都不超过 512 字节，用 UDP 传输即可。不用经过 TCP 三次握手，这样 DNS 服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向 DNS 服务器查询的时候使用 TCP，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。