网络原理03（http协议详细解析2）

一、前文关于http协议请求的总结总结

请求有：

1. 首行：方法 url 版本号，有这三个元素。
2. 请求头：就是键值对
3. 空行
4. 正文，在空行后面才是正文

响应和请求很像

1. 首行：版本号 状态码 状态码描述
2. 响应头：键值对
3. 空行
4. 正文

url部分的案例: 协议名://ip地址(域名):端口号/路径？查询字符串，这里面查询字符串是自定义的，就像"age=20"这样的字符串。

方法有：GET，POST，PUT，DELETE
GET 和 POST 的区别是：1.语义上。2.GET经常把数据放到 url 的query string 中，POST 经常把数据放到 body 中。

二、Host

关于第一行经过介绍，可以简单的看懂一些东西，例如下面这个，POST就是表示这个请求方法是要修改服务器中的数据，后面就跟着域名，在最后跟着http 协议的版本号，接下来是第二行的Host这一行。关于域名和端口后面的资源位置还有'？' 后面的键值对，键值对时使用&这个符号来进行分割的。

Host 在这里表是服务器的主机的地址和端口，cn.bing.com就是服务器的主机的地址，在网络中，POST 携带的域名可能会发生改变，不能直接知道是哪个服务器的地址，但是 Host 是固定不变的，他就是服务器的地址和端口号，所以在确定服务器的时候都会使用Host这一行。
HTTP协议中，传输的时候可能会涉及到“加密”（HTTPS）
url 部分是不会被加密的，被加密的是 header 和 body
服务器收到请求之后也就可以做一个最终校验，验证url中的内容和header的内容是否一致，一致就代表没有被修改，不一致就说明这个请求被修改了。

三、Content-Length

Content-length表示的是body中的数据长度，单位是字节。在请求中有 body 也就是正文，才会有这个属性。

• 没有body的http请求，读到空行就可以认为是结束了
• 有body的http请求，先读取首行和 header，这时候知道了该请求有body，此时读到空行的时候解析 header 中的 Content-Length，根据这里的数值，来决定接下来再固定读取的字节的长度。下面的这个就是352个字节。

HTTP是这样传输的，但是UDP是面向数据报的，读写的单位就是一个 UDP 数据报。如果应用层协议使用UDP，那么一个 UDP 数据报就对应一个完整的应用层数据包，调用一次 receive 操作，就得到一个明确的 UDP 的数据报，就不会和 HTTP 协议一样要通过 Content-Length 这个属性来判断读取的 body(正文) 的长度。

四、Content-Type

Content-Type表示请求的body中的数据格式。表示了接收方怎么解析body中的数据。

• HTMLtext/html 他是网页的格式，浏览器就会解析其中的标签，把标签转换成界面显示
• CSS text/css这是前端的东向西，浏览器就会解析其中的 选择器 和 属性，并且把这里的指定的内容应用到页面的样式上。
• JS application/javascript这是给网页做动态交互效果，浏览器通过 js 引擎解释执行 js 中的逻辑
• JSON application/json浏览器不会做任何处理，直接传过去，这里就需要程序员确定好。
• 图片 image/pong | image/jpg浏览器尝试按照图片的二进制格式解析出来并显示

这里就是使用JS来进行解析，下面的都是JS的语句，是被打乱后的效果，为了防止其他人一拿到就直接使用，JS 中有一定的业务逻辑，所以更需要混淆，而html和css是前端显示，成本比业务成本低，混淆的意义就不大。

如果有body但是没有Content-Type和Content-Length这两个属性，哪怕只有一个，，都会认为是非法的/错误的 http 报文。

五、User-Agent

这个属性是表示了用户使用的设备的浏览器和操作系统的情况

六、Referer

描述了当前页面的来源，就是这个页面是从哪个页面跳转过来的。这里直接输入 url 或者点收藏栏 打开的页面是没有 跳转 也就是没有 Referer 这个属性。下面这个就是从 搜狗 那里跳转过来的。例如使用在广告那里，广告发布商弄一个网址，发给各个浏览器上，通过这个跳转指令就能知道是哪个浏览器跳转过来的。

七、Cookie

Cookie就是浏览器允许网页再根底硬盘存储数据的一种机制，不是让网页代码直接访问文件系统，而是做了一层抽象。Cookie 是按照键值对的方式来存储数据，不是所有网站都是网站自己确认就可以，有些网站需要用户确认是否愿意存本地 Cokie 数据。

Cookie 到哪里去：最终发回给服务器
Cookie 从哪里来：也是从服务器这边来的，由后端开发程序员决定。

Cookie可以使用在用户登录这个场景上，用户输入好账户和密码，通过 Set-Cookie: sessionld = xxxx 像服务器传输一条数据，服务器就去查询数据库，验证你的用户名密码是否有效。如果匹配成功，就会生成 sessionid ,生成 session 对象，把用户的关键信息，保存在 session 对象中，把sessionld和session 对象作为键值对，保存到内存的hash表中，把sessionid，通过Set-Cookie 返回给浏览器。这就是浏览器-服务器之间的联动。下面这个是登陆界面和服务器的简化交互图。

Cookie是可能会过期的，服务器返回Cookie的时候，是可以设置有效时间，如果Cookie中的sessionid 过期了，就需要用户重新登陆了。这就是浏览器中的网页的待机时长，就像银行那里，你五分钟不操作它就会直接给你退出。他就像是一个身份标识，有了它你在这个网页才是合法的，没有这个你就进入不了它的内部系统，你需要一个合适的身份标识来进入这个系统。而保存Cookie就是你的所有信息都在这个标识里面，因为你在这个系统中每次操作都需要验证你的身份，所以每次操作需要验证你的身份的时候就直接使用这个Cookie 就可以免去你再次输入账号密码确认身份这个流程了。