一、应用层
1.含义
应用层负责程序间沟通。我们的网络编程主要是针对应用层。
2.序列化与反序列化
序列化：发送数据时按照某个规则将数据转换为字符串。
反序列化：接收数据时按照相同的规则将字符串转换为数据。
二、HTTP协议
1.URL（Uniform Resource Location)
统一资源定位符，俗称“网址”。
URL的结构：
协议方案://用户名:密码@服务器IP地址:端口/资源路径?查询字符串#片段标识符
http://username:password@server_ip:server_port/path?queryString#id
eg:
例1：
http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
解析：
http: 协议方案名（未加密）
user:pass 登录信息（认证）（一般会省略）
www.example.jp 服务器地址（域名）
80 服务器端口号（一般也省略），在请求发起时默认加上。
/dir/index.htm 带层次的文件路径（资源路径）
uid=1 查询字符串（多个参数间用“&”隔开）
ch1 片段标识符
例2
https://www.so.com/s?ie=utf-8&src=dlm&shb=1&hsid=bcb149e577d70e21&ls=n482bfbdf97&q=C%2B%2B
解析：
https:// 协议方案名（加密）
www.so.com 服务器地址（域名）
/s 资源路径，这里的'/'是相对路径，系统会默认补全路径。（如/home/san/index.htm）
ie=utf-8&src=dlm&shb=1&hsid=bcb149e577d70e21&ls=n482bfbdf97&q=C%2B%2B 查询字符串，格式为key=val&key=val
有些字符，如“/”，“？”，“：”等字符已经被url当作特殊意义理解了，因此这些字符不能随意出现。如果要搜索有关这些字符的信息，就必须先对这些特殊字符进行转义。
转义的规则：将需要转码的字符转为16进制，然后从右到左，取4位（不足4位直接处理），每2位做一位，前面加上%，编码成%XY格式。
2.编码与解码
在URL中，特殊字符都有特殊含义。因此遇到特殊字符，要对它们进行转义（编码）。
编码：提交的数据中，如果存在特殊字符，就必须进行转义。即将特殊字符转为16进制的数字字符串。如C++中的'+'，c++转为16进制变为c2b2b。为了向服务器表明哪些数据是编码后的数据，在编码后的数据前面加上'%'来表示。那么“c++”经过编码就变为"c%2b%2b"。
解码：如果遇到'%'，则认为紧跟其后面的两个字节数据需要进行解码。即根据ASCII码表，将%后面的两个字节进行转换（16进制变为10进制），然后对应ASCII码表找到对应的特殊字符。如"c%2b%2b"，0x2b=2*16+11=43，43对应的ASCII码表得到'+'，最后解码"c%2b%2b"得到"c++"。
3.HTTP协议
3.1 HTTP请求
POST:http://job.xjtu.edu.cn/companyLogin.do HTTP/1.1H
HOST:job.xjtu.edu.cn
Connection:keep-alive
Content-Length:36
Cache-Control:max-age=0
Origin:http://job.xjtu.edu.cn
Upgrade-Insecure-Requests:1
Content-Type:application/X-www-form-urlencoded
User-Agent:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Accept:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Referer:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Accept-Encoding:gzip,deflate
Accept-Language:zh-CN,zh;q=0.8
Cookie:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
username=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
http请求报文主要分为请求行、请求报头、空行和请求正文。按行读取，因此在上面的示例中，Accept属性实际只占一行。
因此，我们可以通过特殊记号空行把报头和报文（有效载荷）有效分离。
请求行主要包括请求方法、请求资源和版本号。
报头的属性
报头中有许多属性，它们都是以Key：Value的方式存放的。
HOST为主机地址，客户端告诉服务器，所请求的资源在哪个主机的哪个端口上。
Connection为连接属性，这里keep-alive指长链接。
Content-Length指正文大小（Body的长度）。
Content-Type指数据类型（如html/text等），这里指超文本传输类型。
User-Agent指用户的操作系统和浏览器版本信息。
Referer指当前页面是从哪个页面跳转过来的。
Location：搭配3XX状态码使用，告诉客户端接下来要到哪里去访问。
Cookie文件用于存放客户端少量信息（主要是用户名和密码（本地）），通常用于实现会话（Session)功能。
关于Cookie：“Cookie”是小量信息，由网络服务器发送出来以存储在网络浏览器上，从而下次这位独一无二的访客又回到该网络服务器时，可以从浏览器读回此信息。关于Cookie的详细内容请见百度百科https://mr.baidu.com/42ue6o0?f=cp
长连接与短连接：
短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开连接，即每次只完成一项业务的发送。
长连接指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。
短连接的操作步骤是：建立连接--发送数据--关闭连接。。。建立连接--数据传输--关闭连接
长连接的操作步骤是：建立连接--数据传输--。。。（保持连接）。。。--数据传输--关闭连接。
http的通信过程:（1）建立连接（2)发送请求（客户端）（3）相应请求并断开连接（服务器端）
3.2 HTTP响应
HTTP/1.1 200 OK
Server:YxlinkWAF
Content-Type:text/html;charset=UTF-8
Content-Language:zh-CN
Transfer-Encoding:chunked
Date:Fri,20 Sep 2018 09:56:52 GMT
<!DOCTYPE html>
<html>
<head>
<title>XXXXXXXXXXXXXXXXXXXXXXXXX</title>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
http响应主要分为状态行（首行）、响应报头、空行和有效载荷，也是”按行陈列"的。
状态行又包括HTTP服务器版本号、状态码和状态码解释。
响应报头和请求报头一样，一行一个属性，并且以Key:Value的方式存放。上面包括了服务器、内容类型、内容语言、传输编码和日期时间等详细信息。
空行后面的内容都是Body，Body允许为空字符串。如果Body存在，则在报头中会有一个Content-Length来标识Body的长度。在这里，服务器返回了一个html页面，那么html页面内容就是在Body中。
3.3 告知服务器意图的HTTP方法
| 方法 | 说明 | 支持的版本号 |
| GET | 获取资源 | 1.0、1.1 |
| POST | 传输实体主体 | 1.0、1.1 |
| PUT | 传输文件 | 1.0、1.1 |
| HEAD | 获得报文首部（即报头） | 1.0、1.1 |
| DELETE | 删除文件 | 1.0、1.1 |
| OPTIONS | 询问支持的方法 | 1.1 |
| TRACE | 追踪路径 | 1.1 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 |
| LINK（UNLINK) | 建立和资源之间的联系（断开连接） | 1.0 |
GET：用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；如果是像CGI（Common Gateway Interface，通用网关接口）那样的程序，则返回经过执行后的输出结果。
POST：用来传输实体的主体。虽然用GET方法也可以传输实体的主体，但一般不用GET方法进行传输，而是用POST方法。虽说POST的功能与GET很相似，但POST的主要目的并不是获取响应的主体内容。
PUT：用来传输文件。就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。但是，鉴于HTTP/1.1的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，因此一般的Web网站不使用该方法。若配合Web应用程序的验证机制，或架构设计采用REST（REpresentational State Transfer，表征状态转移）标准的同类Web网站，就可能会开放使用PUT方法。
HEAD：获得报文首部。HEAD方法和GET方法一样，只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。
DELETE：删除文件。是与PUT方法相反的方法。DELETE方法按请求URI删除指定的资源。但是，HTTP/1.1的DELETE方法本身和PUT方法一样不带验证机制，所以一般的Web网站也不使用DELETE方法。当配合Web应用程序的验证机制，或遵守REST标准时还是有可能会开放使用的。
OPTIONS：询问支持的方法。OPTIONS方法用来查询针对请求URI指定的资源支持的方法。
TRACE：追踪路径。TRACE方法是让Web服务器将之前的请求通信环回给客户端的方法。发送请求时，在Max-Forwards首部字段中填入数值，每经过一个服务器就将该数字减1，当数值刚好减到0时，就停止继续传输，最后接收到请求的服务器端则返回状态码200 OK的响应。客户端通过TRACE方法可以查询发送出去的请求是怎样被加工修改/篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理中转，TRACE方法就是用来确认连接过程中发生的一系列操作。但是TRACE方法本来就不怎么常用，再加上它容易引发XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。
CONNECT：要求用隧道协议连接代理。CONNECT方法要求再与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
POST方法和GET方法的区别（常考）
（1）GET请求参数（提交的数据）直接拼接在url之后，而且参数长度有限制；而POST请求参数（提交的数据）在Body体（正文）中，参数长度没有限制。
实际上，get()本身并没有限制参数长度，真正限制参数长度的是浏览器和Web服务器本身。大部分浏览器限制在2K，而服务器限制在64K。它们都不是定值，各有不同。
（2）浏览器会自动缓存get请求，而post不会自动缓存，除非手动设置。
（3）get请求在浏览器中可回退，而post会再次请求。
（4）get请求时只能通过url编码，而post支持多种编码格式。
（5）get的请求参数可以被完整保存到历史记录中，而post不会被保留。
（6）get产生的url可以被bookmark，而post不可以。
3.4 HTTP的状态码
| | 类别 | 原因短语 | 示例 |
| 1XX | Information(信息状态码) | 接收的请求正在处理 | |
| 2XX | Success(成功状态码) | 请求正常处理完毕 | 200 |
| 3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 | 301、302、303 |
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 | 404 |
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 | 500、503 |
HTTP状态码详解请见HTTP状态码
3.5 HTTP是不保存状态的协议
HTTP是一种不保存状态，即无状态（stateless）协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。使用HTTP协议，每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。
但是，随着Web的不断发展，因无状态而导致业务处理变得棘手的情况增多了。比如，用户登录到一家购物网站，即使他跳转到该站的其它页面，也需要能继续保持登录状态。针对这个实例，网站为了能够掌握是谁发送的请求。需要保持用户的状态。
HTTP/1.1虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
