提示：本文是根据哔哩哔哩源码视频接口测试学习笔记
目录
4. 传输层---建立端口到端口的连接和通信（TCP/UDP协议）
5. 会话层 ---（对传输信息做数据格式的处理 没有协议）
（3）HTTP----请求地址(URL)---统一资源定位符
前言
学习接口测试，首先要了解网络协议，接口是基于协议的。
协议简单来说就是一个约定双方（客户端和服务端）的统一规范，给双方提供连接的桥梁作用。
因为客户端有不同的系统的书写格式如：H5、 安卓系统、iOS系统等，服务端有java、Python、C语言、等等 不同种类的编写语言，每种语言从服务端向客服端传递数据的方式不一样，而不同的客户端接收数据的方式也是不一样的。
接口是由服务端写的，他规定了前端和服务端数据的传递格式，数据的传递主要靠的是协议。
互联网的本质就是一系列的网络协议，这个协议就叫OSI协议（一系列协议），按照功能不同，分工不同，人为的分层七层。实际上这个七层是不存在的。没有这七层的概念，只是人为的划分而已。区分出来的目的只是让你明白哪一层是干什么用的。
每一层都运行不同的协议。协议是干什么的，协议就是标准。
一、OSI七层协议
七层划分为：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
五层划分为：应用层、传输层、网络层、数据链路层、物理层。
四层划分为：应用层、传输层、网络层、网络接口层。
1.物理层 --- 只负责传输二进制电信号（无协议）
字面意思解释：物理传输、硬件、物理特性。在成都的你与北京的朋友聊天，你的电脑必须要能上网，物理体现是什么？是不是接一根网线，插个路由器，北京的朋友那边是不是也有根网线，也得插个路由器。也就是说计算机与计算机之间的通信，必须要有底层物理层方面的连通，就类似于你打电话，中间是不是必须得连电话线。
中间的物理链接可以是光缆、电缆、双绞线、无线电波。中间传的是电信号，即010101...这些二进制位。
底层传输的010010101001...这些二级制位怎么才能让它有意义呢？
要让这些010010101001...有意思，人为的分组再适合不过了，8位一组，发送及接收都按照8位一组来划分。接收到8位为一组的话，那么就可以按照这8位数来做运算。如果没有分组，对方接收的计算机根本就不知道从哪一位开始来做计算，也解析不了收到的数据。我发了16位你就按照16位来做计算吗？我发100位你就按照100位做计算吗？没什么意义是吧。因此要想让底层的电信号有意义，必须要把底层的电信号做分组。我做好8位一组，那么我收到数据，我就知道这几个8位做一组，这几个8位做一组。那么每个8位就可以得到一个确定的数。分组是谁干的活呢？物理层干不了，这个是数据链路层干的。
2.数据链路层 --- 分组、广播（以太网协议）
数据链路层就是来对电信号来做分组的。以前每个公司都有自己的分组方式，非常的乱，后来形成了统一的标准（标准就是协议），即以太网协议Ethernet[ˈiːθənet]。Ethernet规定：一组电信号称之为一个数据包，或者叫做一个“帧”，每一数据帧分成：报头head和数据data两部分。
- head包含：（固定18个字节）
- 发送者(原地址,6个字节)
- 接受者(目标地址,6个字节)
- 数据类型(6个字节)
- data包含：（最短46字节，最长1500字节）
- 数据包的具体内容
- head长度+data长度=最短64字节，最长1518字节，超过最大限制就分包发送。
这就像写信，发送者的地址（源地址）就是你家的地址，接收者地址（目标地址）就是对方的收信地址，路由器就相当于邮局。其实在计算机通信中的源地址和目标地址指的是mac地址。
2.1 Mac地址的由来
head中包含的源和目标地址由来：Ethernet规定接入Internet的设备都必须具备网卡，发送端的和接收端的地址便是指网卡的地址，即Mac地址。
每块网卡出厂时都被烧录上一个实际上唯一的Mac地址，长度为48位2进制，通常由12位16进制数表示，（前六位是厂商编码，后六位是流水线号）
注:怎样查看电脑的Mac地址
方式一 : win+r 打开运行窗口 输入cmd 在命令提示符输入命令 ipconfig /all
方式二 : 控制面板→网络共享中心→更改适配器设置→选择需要查看的网卡→右键状态→详细信息
有了mac地址以后，计算机就可以通信了，假设一个教室就是一个局域网（隔离的网络），这个教室里面有几台计算机，计算机的通信和人的通信是一个道理，把教室里面的人都比作一个个计算机，假设教室里面的人都是瞎子，其实计算机就是瞎子的，计算机通信基本靠吼，现在我要找教室里面的XXX要XXX资料，然后我就吼一声，说我要找XXX要XXX资料，XXX资料就属于我的数据，但是我在发的时候我是不是要标识我是谁，我要找谁，我是谁就是我的mac地址，我要找谁就是飞哥的mac地址，这两个地址做数据包的头部，再加上数据XXX资料就构成了一个数据帧。
这个数据包封装好以后就往外发，到物理层以后就全部转成二级制，往外发是怎么发的呢？就是靠吼。即“我是Edison，我要找XXX要XXX资料”。这么吼了一嗓子以后，全屋子的人都能听到，这就是广播。
计算机底层，只要在一个教室里（一个局域网），都是靠广播的方式，吼。
局域网的理解：什么是互联网，互联网就是由一个个局域网组成，局域网内的计算机不管是对内还是对外都是靠吼，这就是数据链路层的工作方式-----广播。
广播出去以后，所有人都听得见，所有人都会拆开这个包，读发送者是谁，接收者是谁，只要接收者不是自己就丢弃掉。对计算机来说，它会看自己的Mac地址，XXX收到以后，他就会把资料发给我，发送回来同样采用广播的方式了，靠吼。
❤ 同一个教室（同一个局域网）的计算机靠吼来通信，那不同教室的计算机又如何？
比如说局域网1的pc1与局域网2的pc10如何通信？你在教室1（局域网1）吼，教室2（局域网2）的人肯定是听不见的。这就是跨网络进行通信，数据链路层就解决不了这个问题了，这就得靠网络层出面了。
在讲网络层之前，其实基于广播的这种通信就可以实现全世界通信了，你吼一声，如果全世界是一个局域网，全世界的计算机肯定可以听得见，从理论上似乎行得通，如果全世界的计算机都在吼，你想一想，这是不是一个灾难。因此，全世界不能是一个局域网。于是就有了网络层。
3.网络层:---网关（IP协议）
网络层定义了一个IP协议
你想，我是这个教室的一个学生，我想找隔壁教室一个叫老王的学生，我也不认识老王，那怎么办，我吼？老王在另外一个教室肯定是听不到的。找教室的负责人，这个教室的负责人就负责和隔壁教室的负责人说话，说我们教室的有个学生要找你们教室的老王。往外传的东西交给负责人就可以了，内部的话上面已经提到，通过广播的方式，对外的东西广播失效。教室的负责人就是网关，网关即网络关口的意思。
Mac地址是用来标识你这个教室的某个位置，IP地址是用来标识你在哪个教室（哪个局域网）。你要跨网络发包你是不是要知道对方的IP地址，比如你要访问百度，你肯定得知道百度服务器的IP地址。计算机在发包前，会判断你在哪个教室，对方在哪个教室，如果在一个教室，基于mac地址的广播发包就OK了；如果不在一个教室，即跨网络发包，那么就会把你的包交给教室负责人（网关）来转发。Mac地址及IP地址唯一标识了你在互联网中的位置。
数据链路层中会把网络层的数据包封装到数数据链路层的数据位置，然后再添加上自己的包头，再发给物理层，物理层发给网关，网关再发给对方教室的网关，对方教室的网关收到后在那个教室做广播。
在数据链路层看，数据封装了两层，跟玩俄罗斯套娃有点类似，一层套了一层。
※ DHCP协议（动态主机配置协议，是一个局域网的网络协议） 可以分配ip
最终变成
现在来看另一个问题，在吼之前怎么知道对方的Mac地址？这就得靠ARP协议。
ARP协议的由来：在你找张三要资料之前，你的先干一件事，想办法知道张三的Mac地址。即你的机器必须先发一个ARP包出去，ARP也是靠广播的方式发，ARP发送广播包的方式如下：
局域网中怎么获取对方的Mac地址：
肯定要知道对方的IP地址，这是最基本的，就像你要访问百度，肯定得知道百度的域名，域名就是百度的IP地址。自己的IP可以轻松获得，自己的Mac也轻松获取，目标Mac为12个F，我们叫广播地址，表达的意思是我想要获取这个目标IP地址172.16.10.11的机器的Mac地址。Mac为12个F代表的是一种功能，这个功能就是获取对方的MAC地址，计算机的Mac永远不可能是12个F。假设是在本教室广播，一嗓子吼出去了，所有人开始解包，只有IP地址是172.16.10.11的这个人才会返回他的Mac地址，其他人全部丢弃。发回来源Mac改成张三自己的Mac地址，同时把张三的Mac地址放在数据部分。
跨网络怎么获取对方的Mac地址：
通过IP地址区分，计算机运算判断出张三不在同一个教室，目标IP就变成了网关的IP了。网关的IP在计算机上配死了，可以轻松获取。
这样网关就会把它的Mac地址返回给你，然后正常发包
网关帮你去找收件人，但对用户来说，我们根本就感觉不到网关的存在。
4. 传输层---建立端口到端口的连接和通信（TCP/UDP协议）
传输层的由来：网络层的ip帮我们区分子网，以太网层的mac帮我们找到主机，然后大家使用的都是应用程序，你的电脑上可能同时开启qq，暴风影音，等多个应用程序，那么我们通过ip和mac找到了一台特定的主机，如何标识这台主机上的应用程序，答案就是端口，端口即应用程序与网卡关联的编号。
传输层功能：建立端口到端口的通信
补充：端口范围0-65535，0-1023为系统占用端口
4.1 Tcp协议
可靠传输，TCP数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包不必再分割。
4.2 Udp协议
不可靠传输，”报头”部分一共只有8个字节，总长度不超过65,535字节，正好放进一个IP数据包。
※ 对传输的数据有长度都有一定限制 ，超过就分包
5. 会话层 ---（对传输信息做数据格式的处理 没有协议）
在得到需要连接对象的信息之后（mac、ip、端口号）负责对两个不同实体的表示层之间建立连接。（加密解密 数据转化 编码）
6. 表示层
将用户传来的信息（应用层的命令或数据）进行翻译，如编码、数据格式转换、加密解密等。
7. 应用层---HTTP协议等
应用层由来：用户使用的都是应用程序，均工作于应用层，互联网是开发的，大家都可以开发自己的应用程序，数据多种多样，必须规定好数据的组织形式 。
应用层功能：规定应用程序的数据格式。
例：TCP协议可以为各种各样的程序传递数据，比如Email、WWW、FTP等等。那么，必须有不同协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了”应用层”。
发送端经过每一层添加首部,接收端经过每一层删除首部
数据先由上往下将数据装包，然后由下往上拆包;在装包的时候，每一层都会增加一些信息用于传输，这部分信息就叫报头，当上层的数据到达本层的时候，会将数据加上本层的报头打包在一起，继续往下传递．在拆包的时候，每一层将本层需要的报头读取后，就将剩下的数据往上传．
（二）TCP/IP协议族
1.TCP协议
（1） 什么是TCP协议
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。之后TCP把数据包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。
Tcp协议包头:
src port：源端口，2个字节，是一个大于1023的16位数字，由基于TCP应用程序的用户进程随机选择
dst port：目的端口，2个字节，指明接收者所用的端口号，一般由应用程序来指定
Sequence number：顺序号，4个字节，用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 (2^32) － 1 后又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN （ Initial Sequence Number ）
Acknowledgement number：确认号，4个字节，包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效
Offset：报头长度，4位，给出报头中 32bit 字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ， 即TCP 最多有 60（15*4） 字节的首部
Resrvd：保留区域，6位，保留给将来使用，目前必须置为 0
Control Flags（6位）控制位包括
**URG**：为 1 表示紧急指针有效（出问题），为 0 则忽略紧急指针值
**ACK**：为 1 表示确认号有效（确实收到对方的信息），为 0 表示报文中不包含确认信息，忽略确认号字段
**PSH**：为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满
**RST**：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题
**SYN**：同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步（ synchronize ）
**FIN**：用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流
Window Size：窗口大小，2个字节，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535（2^16 - 1）
Checksum：校验和，2个字节，对整个的 TCP 报文段（包括 TCP 头部和 TCP 数据），以 16 位字进行计算所得。这是一个强制性的字段，要求由发送端计算和存储，并由接收端进行验证
Urgent Pointer：紧急指针，2个字节，是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。 只有当URG 标志置 1 时紧急指针才有效
Option and Pad：选项和填充，n*4字节，常见的可选字段是最长报文大小 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数
Data：数据，不定长度，为上层协议封装好的数据
最大报文段长度MSS（Maximum Segment Size）
指明自己期望对方发送TCP报文段时那个数据字段的长度。比如：1460字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS写入这一字段。MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中
MTU和MSS值的关系：MTU=MSS+IP Header+TCPHeader
通信双方最终的MSS值=较小MTU-IP Header-TCP Header
（2） TCP三次握手(建立连接)（重点）
第一次握手：客户端首先向服务器发起连接，这时TCP头部中的SYN标识位值为1，然后选定一个初始序号seq=x（一般是随机的），消息发送后，客户端进入SYN_SENT状态，SYN=1的报文段不能携带数据，但要消耗一个序号。
第二次握手:服务器收到客户端的连接请求后，同意建立连接，向客户端发送确认数据，这时TCP头部中的SYN和ACK标识位值均为1，确认序号（具体应答号）为ack=x+1，然后选定自己的初始序号seq=y（一般是随机的），确认消息发送后，服务器进入SYN_RCVD状态，与连接消息一样，这条消息也不能携带数据，同时消耗一个序号。
第三次握手：客户端收到服务器的确认消息后，需要给服务器 回复确认数据，这时TCP头部中的ACK标识位值为1，确认序号是ack=y+1，自己的序号在连接请求的序号上加1，也就是seq=x+1，此时A进入ESTABLISHED状态，当服务器收到客户端的确认回复后，服务器也进入ESTABLISHED状态，至此TCP成功建立连接，客户端和服务器之间就可以通过这个连接互相发送数据了。
黑客攻击时就是攻击第三次客户端返回链接， 模拟多个虚拟ip用户 同时发送给服务器，占用通信通道， 正常用户无法建立连接，syn攻击
（3） TCP四次挥手(释放连接)
初始状态：客户端A和服务器B之间已经建立了TCP连接，并且数据发送完成，打算断开连接，此时客户端A和服务器B是等价的，双方都可以发送断开请求，下面以客户端A主动发起断开请求为例。（后续内容用A，B简称代替）
1.A首先向B发送断开连接消息，这时TCP头部中的FIN标识位值为1，序号是seq=u，u为A前面正常发送数据最后一个字节序号加1得到的，消息发送后A进入FNI_WAIT_1状态，FIN=1的报文段不能携带数据，但要消耗一个序号。
2.B收到A的断开连接请求需要发出确认消息，这时TCP头部中的ACK标识位值为1，确认号为ack=u+1，而自己的序号为seq=v,v为B前面正常发送数据最后一个字节序号加1得到的，然后B进入CLOSE_WAIT状态，此时就关闭了A到B的连接，A无法再给B发数据，但是B仍然可以给A发数据，同时B端通知上方应用层，处理完成后被动关闭连接。然后A收到B的确认信息后，就进入了FIN_WAIT_2状态。
3.B端应用层处理完数据后，通知关闭连接，B向A发送关闭连接的消息，这时TCP头部中的FIN和ACK标识位值均为1，确认号ack=u+1，自己的序号为seq=w，（B发出确认消息后有发送了一段数据，此处存疑），消息发送后B进入LAST_ACK状态。
4.A收到B的断开连接的消息后，需要发送确认消息，这是这时TCP头部中的ACK标识位值为1，确认号ack=w+1，序号为u+1（因为A向B发送断开连接的消息时消耗了一个消息号），然后A进入TIME_WAIT状态，若等待时间经过2MSL后，没有收到B的重传请求，则表明B收到了自己的确认，A进入CLOSED状态，B收到A的确认消息后则直接进入CLOSED状态。至此TCP成功断开连接。
（4） Syn攻击
在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RCVD状态.当收到ACK后，服务器转入ESTABLISHED状态.Syn攻击就是攻击客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击netstat -n -p TCP | grep SYN_RCVD
一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.但是不能完全防范syn攻击。
（5）常见问题
1、 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步 作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了， 所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里 的ACK报文和FIN报文多数情况下都是分开发送的。
2、 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为：虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状 态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于 LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的 ACK报文。MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。
3. 为什么不能用两次握手进行连接？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4. 如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
（6） 名词解释
- CLOSED: 这个没什么好说的了，表示初始状态。
- LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
- SYN_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
- SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
- ESTABLISHED：这个容易理解了，表示连接已经建立了。
- FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
- FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
- TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带 FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
- CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
- CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
- LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
（7）常见的协议
1：超文本传输协议HTTP：这是一种最基本的客户机/服务器的访问协议；浏览器向服务器发送请求，而服务器回应相应的网页
2：文件传送协议FTP：提供交互式的访问，基于客户服务器模式，面向连接 使用TCP可靠的运输服务
主要功能:减少/消除不同操作系统下文件的不兼容性
3：远程登录协议TELNET：客户服务器模式，能适应许多计算机和操作系统的差异，网络虚拟终端NVT的意义
4：简单邮件传送协议SMTP：Client/Server模式，面向连接
基本功能：写信、传送、报告传送情况、显示信件、接收方处理信件
5：DNS域名解析协议：DNS是一种用以将域名转换为IP地址的Internet服务
6：简单文件传送协议TFTP：客户服务器模式，使用UDP数据报，只支持文件传输，不支持交互，TFTP代码占内存小
7：简单网络管理协议（SNMP）: SNMP模型的4个组件：被管理结点、管理站、管理信息、管理协议
- SNMP代理：运行SNMP管理进程的被管理结点
- 对象：描述设备的变量
- 管理信息库（MIB）：保存所有对象的数据结构
8:DHCP动态主机配置协议: 发现协议中的引导文件名、空终止符、属名或者空,DHCP供应协议中的受限目录路径名 Options –可选参数字段，参考定义选择列表中的选择文件
9:TCP：传输控制协议，传输效率低，可靠性强
10:UDP：用户数据报协议，适用于传输可靠性要求不高，数据量小的数据（比如QQ）
2. HTTP协议
（1） 什么是http协议
HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
（2） http特点
1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
3.无连接：无连接的含义是限制每次连接只处理一个请求（HTTP本身的状态）。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
5、支持B/S及C/S模式。
（3）HTTP----请求地址(URL)---统一资源定位符
HTTP 使用统一资源标识符（ Uniform Resource Identifiers, URI） 来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息
URL,全称是 Uniform Resource Locator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：
1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符
2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用
3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口，端口号标明在系统中启动的是哪个应用，一个应用占用一个端口号，
- HTTP端口号：80
- HTTPS端口号：443
- （指占用服务器的端口，对于http协议若不标明端口默认是80，而自己搭建的项目，自带端口号是8080，是自己定义的端口，如Apache\Tomcat服务器，默认占用系统端口是8080，）
4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”，（域名后的第一个“/”表示的是项目在服务器部署的根目录（虚拟目录））
5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分
7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
（4）HTTP----请求消息(Request)
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。
Get请求例子，使用Fiddler抓取的request：
第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等
第三部分：空行，请求头部后面的空行是必须的
即使第四部分的请求数据为空，也必须有空行。
第四部分：请求数据也叫主体，可以添加任意的其他数据。
这个例子的请求数据为：name=zhangsan&age=18。
POST请求例子，使用fiddler抓取的request：
HTTP请求信息：
第一部分：请求行， 请求方式（post/get）+url+协议版本号（http1.1版本）
第二部分：请求头部，到空行中间部分是请求头
- host：域名
- connection：
- content-length：
- Accept：是允许接收的数据，可以接收json格式、JavaScript、TXT，两个*表示所有格式都接收
- origin：
- user_agent:显示客户端的设备信息：浏览器和操作系统，
- content_type：
- Referer:表示地址来源，显示客户端是直接输入的地址还是通过某些链接进入的，便于统计分析客户属性（用来区分老用户/新用户）
- Accept-Encoding: gzip, deflate, br 接收的编码方式
- Accept-Language: zh-CN,zh;q=0.9 接收的语言
- cookie：存储的用户信息
第三部分：空行，不包含任何信息;
第四部分：请求数据，请求体（也称请求参数）：空行后剩余部分，
HTTP请求（request）包含四部分
- 请求行
- 包含：
- 请求方式：get/post
- 域名 （host）
- 协议版本
- 包含：
- 请求头
- cookie ：用户信息
- content_type ：决定请求参数类型
- user_agent ： 请求设备信息
- 空行
- 请求体
- 请求参数
例：
（5） HTTP----响应消息(Response)
一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）
第二部分：消息报头，用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头，
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
第三部分：空行，消息报头后面的空行是必须的
第四部分：响应正文，服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。
- 状态行：HTTP/1.1 200 OK
- HTTP协议版本号 --- HTTP/1.1
- 状态码 --- 200 OK
- 响应头：第二行到空行中间是响应头
- 服务器设备信息 --- server：Apache(说明 访问的服务器应用是搭建在Apache上的)
- 连接 --- connection ： Keep-alive （长连接）---保证用户在只用过程中保持连接
- 缓存 --- Cache-Control : no-cache （没有缓存）
- 访问时间 --- date
- 内容长度 --- content-Length 单位：字节（指的是响应体的返回长度）
- 空行：
- 响应体（也称返回值）：空行后面部分，接口中称为返回值
- 返回值--- 响应内容
- 经典项目环境：Apache(中间件) + MySQL（数据库）+php（后台语言）+Linux(系统) LAMP
※做接口测试必须要知道两部分： 接口的请求参数（请求体）和返回值（响应体）
（6） HTTP----头信息(headers)
① HTTP Request Header 请求头
| Header | 解释 | 示例 |
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close.Keep-Alive |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的Email | From: user@email.com |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
② HTTP Responses Header 响应头
| Header | 解释 | 示例 |
| Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括实现特定的指令，它可应用到响应链上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
| refresh | 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持） |
Refresh: 5; url= http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果实体暂时不可取，通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
| Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
| Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
（7） HTTP----状态码(status_code)
- 状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:
- 状态码显示的是服务器对客户端发送请求的处理状态
1. 1xx：指示信息--表示请求已接收，继续处理
2. 2xx：成功--表示请求已被成功接收、理解、接受
3. 3xx：重定向--要完成请求必须进行更进一步的操作
4. 4xx：客户端错误--请求有语法错误或请求无法实现
5. 5xx：服务器端错误--服务器未能实现合法的请求
常见状态码：
- 200 OK
- //客户端请求成功，服务器已成功处理请求
- 只能说明客户端和服务器建立连接是通畅的，
- 但不代表返回的数据是你想要的，只是物理状态的返回
- 301
- 永久重定向（数据转移到其他地方）
- 303
- 临时重定向
- 400 Bad Request
- //客户端请求有语法错误，不能被服务器所理解
- 401 Unauthorized
- //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
- 403 Forbidden
- //服务器收到请求，但是拒绝提供服务
- 404 Not Found
- //请求资源不存在，eg：输入了错误的URL
- 500 Internal Server Error
- //服务器发生不可预期的错误
- 503 Server Unavailable
- //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
（8） HTTP----请求方法(send_method)
根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法： get, post 和 head方法。
HTTP1.1新增了五种请求方法：options, put, delete, trace 和 connect 方法。
- get --- （查询）
- 请求指定的页面信息，并返回实体主体。
- 从服务器中获取资源
- head
- 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
- post --- （新建）
- 向服务器中添加资源。向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。
- 数据被包含在请求体中。
- post 请求可能会导致新的资源的建立和/或已有资源的修改。
- put --- （修改）
- 从客户端向服务器传送的数据取代指定的文档的内容，如用户信息的修改或库存的修改。
- delete --- （删除）
- 请求服务器删除指定的页面。
- connect
- HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
- options
- 允许客户端查看服务器的性能。
- trace
- 回显服务器收到的请求，主要用于测试或诊断。
（9）HTTP----运行原理（背）
在浏览器地址栏输入一串url,按回车后只到页面渲染成功经历了什么?
1、首先，在浏览器地址栏中输入url，先解析url，检测url地址是否合法
2、浏览器先查看浏览器缓存-系统缓存-路由器缓存，如果缓存中有，会直接在屏幕中显示页面内容。若没有，则跳到第三步操作。
浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)；
路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
ISP缓存：若上述均失败，继续向ISP搜索。
3、在发送http请求前，需要域名解析(DNS解析)，解析获取相应的IP地址。
4、浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手。
5、握手成功后，浏览器向服务器发送http请求，请求数据包。
6、服务器处理收到的请求，将数据返回至浏览器
7、浏览器收到HTTP响应
8、浏览器解码响应，如果响应可以缓存，则存入缓存。
9、浏览器发送请求获取嵌入在HTML中的资源（html，css，javascript，图片，音乐······），对于未知类型，会弹出对话框。
10、浏览器发送异步请求。
11、页面全部渲染结束。
（10） Cookie & Session & Token
Cookie 机制：正统的Cookie 分发是通过扩展HTTP 协议来实现的，服务器通过在HTTP 的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的Cookie。然而纯粹的客户端脚本如JavaScript 或者VBScript也可以生成Cookie。而Cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的Cookie，如果某个Cookie 所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie 附在请求资源的HTTP 请求头上发送给服务器。
Session 机制：Session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
Cookie 固然好，但存在一定的安全隐患。Cookie 像我们以前用的存折，用户的存钱、取钱都会记录在这张存折上（即浏览器中会保存所有用户信息），那么对于有非分想法的人可能会去修改存折上的数据（这个比喻忽略掉银行同样会记录用户存取款的金额）。
相对于存折，银行卡要安全的得多，客户拿到的只是一个银行卡号（即浏览器只保留一个Sessionid），那么用户的存钱、取钱都会记录在银行的系统里（即服务器端），只得到一个sessionid 是没有任何意义的，所以相对于Cookie 来说就会安全很多。
Cookie是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
Cookie由服务器生成，通过响应头Set-Cookie字段发送给浏览器，浏览器把Cookie以key value形式保存到某个目录下的文本文件里，下一次请求同一网站时会把该Cookie发送给服务器。由于Cookie是存在客户端上的，所以浏览器加入了一些限制确保Cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的Cookie数量是有限的。
Session从字面上讲，就是会话。服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，默认采用Cookie的方式。
服务器使用Session把用户的信息临时保存在了服务器上，用户离开网站后Session会被销毁。这种用户信息存储方式相对Cookie来说更安全，可是Session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候Session会丢失。
Token意思是“令牌”，用户身份的验证方式，有点类似于Cookie，相对来说更安全。
比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；Cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用Cookie自动登录用户名；Session和Cookie差不多，只是Session是写在服务器端的文件，也需要在客户端写入Cookie文件，但是文件里是你的浏览器编号。Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。
最简单的Token组成：uid（用户唯一的身份标识）、time（当前时间的时间戳）、sign（签名，由Token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接Token请求服务器）。还可以把不变的参数也放进Token，避免多次查库。
Token特点：
1、无状态、可扩展；
2、支持移动设备；
3、跨程序调用；
4、安全。
一般流程：
1、客户端向服务端申请Token；
2、服务端收到请求，会去验证用户信息，签发一个Token给客户端，服务端自己也会保存 Token；
3、客户端收到服务端签发的Token会保存起来，每次请求带上Token；
4、服务器收到其他请求，会去验证客户端的Token，如果成功则返回数据，不成功做其他处理。
236
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
