注：此博文为本人学习过程中的笔记
在网络初始中谈到TCP/IP五层模型，接下来我们将介绍这里面涉及到的网络协议。
应用层是程序员接触最多的层次，程序员写的代码只要涉及到网络通信都可以视为是应用层的一部分。应用层里的东西和程序员直接相关，应用层涉及的网络协议很多也是程序员自定制的。
1.自定义协议
自定义协议分成两个阶段
1.根据需求明确需要传输哪些信息
2.约定好信息组织的格式
这里我们以外卖平台为例
1.明确传输信息
请求：用户的位置信息，用户的id
响应：商家的id，商家的名字，商家的图片，评分，配送费，种类
2.约定组织信息的格式
1.行文本
这里的方案是随便写的，实际使用的使用可以随心所欲的使用。
请求：1000,45E45N\n
响应：1,麦当劳,商家图片.jpg,5,3,快餐\n
这个方案比较古老，现在已经不使用了。
2.xml格式
xml是通过成对的标签构成的键值对结构
请求：
<request>
<userId>1000</userId>
<position>45E45N</position>
</resquest>
xml格式现在使用的也不多了，它的优点是可读性强，缺点是冗余信息太多，消耗更多的带宽。
3.json
{
"userId":1000,
"positon":"45E45N"
}
json是现在常用的方案，优点是可读性号，需要消耗的带宽也比xml小，缺点是仍然存在冗余信息。
4.protobuf
protobuf基于二进制的格式对数据进行压缩，不涉及到xml/json的冗余信息的，但是可读性很差
经常在性能需求高的场景使用。
2.现成协议
应用层这里除了自定义协议，还有一些大佬们已经现成搞好的协议。比如FTP文件传输，SSH远程操作主机，telnet网络调试工具等，其中最重要的是HTTP协议（HTTPS是在HTTP的基础上加上安全层SSL）。
1.HTTP 协议
应用层协议
HTTP是采用一问一答的协议模式，客户端发送一个请求，服务器就返回一个响应，请求和响应一一对应。网络协议中也有其他模型，多问一答（上传大文件），一问多答（下载大文件），多问多答（远程操作桌面）。这里我们以访问b站网页的请求和响应为例。
下图是请求
下图是响应
HTTP协议是一个文本格式的协议，请求有首行，请求头，空行，正文。响应有首行，响应头，空行，正文。下面对各个细节进行解析。
1.url
url是用来描述网络上唯一资源的位置的，以下是url的格式。
协议类型/ip(域名):端口号/路径?查询字符串
2.url encode
url中本身有一些特殊字符来标识特定含义，url里query string里的内容是程序员自定义的，如果这里面也有特殊字符的话就需要使用api进行转义操作。转义操作就是将数据的二进制内容每个字节取出来，转成十六进制，并在前面加上百分号。
3.方法
GET
获取html，获取css，获取js等操作都是用GET方法
POST
登录，上传文件等是典型的使用POST的场景
GET和POST的区别
1.语义上的区别
2.携带数据的方式不同，GET是使用query string，而POST是使用正文。当然这是理论上的，GET也可以使用正文，而POST也可以使用query string。
3.GET通常是建议被设计成幂等的，而POST无要求。幂等就是指我给出特定的请求就会返回特定的响应。不过现在的场景幂等已经变少了，因为现在讲究个性化。
4.GET设计成幂等就可以让GET的内容被缓存，而POST的则不行。
一些有问题的说法
1.POST比GET更安全。这个说法主要是针对登录场景，因为GET的数据是写在query string里的，所以不安全。安不安全取决于是否加密传输，就算放在query string里，只要加密好也没什么问题。POST的数据如果没加密也可以使用抓包工具简单的获取到。
2.GET传输数据长度有限制。这个说法是针对古早的场景（windowsxp）的。那是的浏览器对url的长度有限制。现在有些有，有些没有，不多就算有，浏览器提供的长度也是够用的。
3.GET只能放文本，POST可以放二进制。这个说法是因为url里只能放文本，不过我们可以把二进制数据转义成文本，这样GET也可以放二进制数据了
DELETE/PUT
这两个方法主要是实现Restful风格的api会使用到。Restful是一种设计服务器接口的习惯。POST表示增，DELETE表示删，PUT表示改，GET表示查。不过实际上这四个方法都可以进行增删改查，取决于代码怎么写。
4.header
header是键值对结构，每一行是一个键值对，键和值之间使用 : 和空格分割。键和值的内容都是标准规定的。
Host
表示服务器主机的地址和端口
Content-Length/Content-Type
当有 body 时才会有这两个东西。如果有 body，却没有这两个（或者少了其中一个）的话，都认为这是一个错误的 HTTP 报文。
Content-Length 表示 body 中的数据的长度，单位是字节。TCP 服务器在连接后可以发送多个请求，因为数据是以字节为单位来传输的，所以需要知道 body 的长度来分割每个请求。
Content-Type 表示 body 中数据的格式。HTTP 可以携带的数据种类很多，有 HTML, JS, CSS, JSON, 图片等，此时就可以提示接收方要怎么解析数据。
User-Agent
可以通过 User-Agent 提供的浏览器版本和操作系统来判断用户的情况，从而决定浏览器的特性。
Referer
描述了当前界面的来源，也就是从哪个页面跳转过来的
Cookie
在浏览器展示页面的过程中，虽然可以使用 js 实现一些逻辑，但是 js 代码是不能访问你的硬盘的。不过在实际开发中，我们还是希望能把某些数据保存到本地硬盘中，因此就引入了 Cookie 机制。
Cookie 就是浏览器允许网页保存数据到本地硬盘的一种机制，不是让网络代码直接访问硬盘，而是做了一层抽象，Cookie 提供了键值对的储存机制。
浏览器从服务器保存了 Cookie 之后，在后续请求中就可以将这些 Cookie 的键值对放到请求头里的 Cookie 中，发送给服务器。
Cookie 里的数据都是程序员自定义的，与业务相关。有一个典型的场景就是登录和用户认证。
5.状态码
描述了响应结果是正确还是出错，出错的原因是什么，下面介绍一些常用的。
200 OK
最常见的状态码，表示成功。
404 Not Found
访问的资源没找到。在url里，ip定位到服务器，port定位到程序，path定位到程序管理的资源，这里就是path定位的资源服务器找不到。
403 Forbidden
访问被拒绝（没有权限）
405 Method Not Allowed
请求的方法和服务器这边声明的注解不匹配时，就会出现。
500 Internal Server Error
服务器出现问题，比如服务器代码抛出异常而我们没有 catch 到时。
504 Gateway Timeout
网关出现问题
302 Move Temporarily
重定向
总结
2xx 都可以视为是成功
3xx 都是重定向
4xx 客户端出错，用户构造的请求有问题
5xx 服务器出错，出现大概率是程序员的代码有问题
有些状态码的描述是比较含糊的，所以当出现问题时，需要结合代码定位问题。
2.HTTPS 协议
应用层协议
HTTPS 协议就是HTTP 协议加上 SSL协议，这个 SSL 协议也是一个应用层协议，专门负责加密。
加密方式存在对称加密和非对称加密，对称加密就是加密和解密都使用同一个密钥，非对称加密就是加密使用一个密钥，解密使用另一个密钥。
1.工作原理
当服务器和客户端进行传输数据时，如果使用对称加密，尽管数据是密文传输，但是密钥是明文传输，会被获取到。
所以这里我们引入非对称加密对密钥进行加密，由服务器持有私钥，并发放公钥给客户端。因为非对称加密成本比较高，不适合用来加密大量数据，所以用来加密密钥。
在这里黑客虽然能获取到公钥，但这是非对称加密，只有私钥才能用来解密。
2.安全问题
这样的流程看起来不错，但存在重大的安全隐患，会破坏后续传输的安全性。这个问题就是中间人攻击
预防这个问题的关键就是客户端需要能校验获取到的这个公钥是否是服务器发送过来的那个。这里引入了证书这个校验机制。
3.UDP协议
传输层协议
UDP是无连接，不可靠，面向数据报，全双工的。接下来先认识报文结构
端口号
因为端口号的长度是两个字节，所以它的取值是有限制的，从0到65535，一般我们会把1024以下的端口号保留，所以取值一般是1024到65535
长度
这个长度表示整个UDP数据报的长度（报头 + 载荷），长度属性也是两个字节，0到65535，也就是64kb。这个长度如果不够用的话，就只能通过TCP协议去传输数据了，因为TCP数据没有长度限制
校验和
验证数据是否发生修改，主要是为了防止传输过程中出现比特翻转。
发送之前，会使用整个数据报的数据计算一个校验和，之后把校验和和数据报一起发送出去，接收方收到之后重新计算一个校验和来进行比对，发现校验和不一样就会丢弃数据。
UDP的校验和使用CRC（循环冗余校验）的方式进行过校验，就是把每个字节（除校验和之外的）数据都当作整数进行累加，溢出也没关系，继续加。