目录
我们从本节开始，就来正式地详细介绍网络各个层次的内容。
我们先从最顶端的应用层协议说起。
在说应用层协议之前，我们来思考一下什么叫协议？
协议
协议是一种 "约定". socket api的接口, 在读写数据时, 都是按 "字符串" 的方式来发送接收的。更准确点来说，收发是按照比特位的形式进行的。
对于协议的理解，抓住本质：它就是一种协议。有了这种协议，大家都遵守的协议，那么在不同的主机收发数据的时候，就有了读取的标准，这样在序列化和反序列化、读取大小等都有了参照的标准。
那么作为IOS模型的最顶端——应用层协议，都有哪些特点呢？我们现在就来详细地讨论一下。
本节，我们的应用层协议主要以Http为例，主要学习http的报文格式、特性等。
HTTP协议
首先需要明确的是，对于包含http协议在内的应用层协议，不属于内核，都是由程序员自己来定的。也就是说，http的报文格式到底是怎么样的，是程序员自己决定的。
认识URL
比如我现在有这样一个所谓的链接：https://translate.google.cn/?sl=auto&tl=zh-CN&text=%20contiguous%20characters&op=translate
这样的链接，我们称之为URL
这样的一个URL，我们可以分成这样几块：
前面的https，为协议名；即我所使用的协议是https协议。
而后面的translate.google.cn或者是sports.qq.com，它们都是服务器地址；
再往后不同的链接就不一样了。大多数都是带层次的文件名、字符串查询符号、文段标识符等。
当然，在一个URL里，通常也会包含登录信息和端口号。但是我们这个通常不写。前者是因为浏览器知道你是谁，而后者是因为协议和端口一般是强绑定。比如https绑定的端口号就是443。
HTTP协议的特征
三个特征：
1、无状态；
2、无连接；
3、简单快速。
重点来解释前两个。
先来解释第一个：HTTP是建立在TCP协议的基础之上，那这和底层基于TCP协议是不是矛盾呢？其实之前就已经说过，HTTP作为上层，是不关心底层（下面一层）具体是怎么实现的细节的。
换句话来说：你TCP链不链接和我HTTP没有丝毫的关系。
所以说，HTTP直接把数据和报文的request发给底层的TCP就可以了，不需要考虑和对方链接的问题，至于要通过链接解决可靠性等问题，那是你底层TCP的事情，与我HTTP无关。所以说http是可以不用保证可靠性的（简而言之就是，因为http是基于tcp的，而tcp保证了可靠，所以http就不用保证啦）。
无状态：http本身是无状态的，并不会记录任何用户信息，只会发出request，然后得到response。记录你访问信息的是cookie + session
短链接进行文本传输（文本：html,img,css,js…）http/1.0
现在的http/1.1:也支持长连接
再来说说简单快速吧：简单是说其就是基于简单的链接，一来一回响应一个request和response就完了。 快速高效就也体现在其底层用的是tcp，并且可以传送各种文本资源。
HTTP的构成及报文格式
报文格式
http的报文分为两大类：
request报文和response报文
request报文和response报文的格式如下：
（1）在http报文的第一行是请求行，包含请求方法、url和 http的版本(version)（2）
（2）然后在下面的若干行，是一些key/value值；主要是一些属性。比如用户名、是否为长连接等。
（3）然后是空行；
（4）最后是请求报文的正文部分。
（还是先去接受，因为我这些知识本身就是一个闭环，只有把这些知识全都介绍完之后，才能够明白来龙去脉）
对于Response报文：
（1）如上图，与Requst报文类似，response报文分为四块。分别是相应行、响应报头、空行和响应正文。
在第一行的响应行里，首先是response的版本，然后是退出状态码，接着是对退出状态码的描述。
（2）接下来的若干行依旧是响应报头的key/value值，存储的是一些属性。值得注意的是，这里面包含一行为Content-Length，它表示的是对应响应正文的大小。
（3）再接下来是一行空行。
（4）然后是响应正文部分。
整个过程如下图所示：
当服务器收到一个request后，需要返回一个response
一次响应、一次请求结束之后，如果是短连接，那么短连接结束，服务端的文件描述符直接close掉，连接断开。
对于报文的内容，我们一会还会详细叙述，现在，我们来说一说该报文的可行性（即实际可操作性）：
问：即我作为读的一方，我怎么知道我已经将HTTP的请求包括数据全部读完了呢？
答：首先，由于其是 以行 为单位来去写的，所以，就要以行为单位来去读。
所以当读到\n的时候，我就知道我这一行读完了
当我读到空行的时候，我就知道我已经把报头读完了。
下面的正文该读多少，取决于在请求报头当中的key值后面的value.(即其中一个key:value所表明的就是请求正文里有多少个字节，具体来说是Content-length:xxx，所以读取的时候，只要根据这个数值来就可以了)（注意，由于许多个http请求报文可能是连在一块的，所以是需要这个读取数值的，不是一股脑的将所有的数据全部读完）
注意：由于HTTP上层已经没有协议了，所以其不需要解决交付的问题，只需要解决分离的问题就可以了。
好的，我们现在来介绍一些细节。
请求方法
我们上网一般就干两件事：把人家的数据拿下来，或者将数据上传到网站上
那么在请求报文中，体现出来的就是POST方法和GET方法。POST就表示我要将我的报文的数据传递到某个网站上；GET相反，表示我要从某个网站上获取信息。
当然，我们的请求方法不止POST和GET两种。具体见下图：
常见的Header
这里的Header的意思就是报头上的key : value的key值。
它通常会有如下这些（这些通常也是比较常见、比较基本的）：
1、Content-Type: 数据类型(text/html等)
2、Content-Length: Body的长度
3、Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
4、User-Agent: 声明用户的操作系统和浏览器版本信息; （可以通过判断是否携带该信息来判断是否为机器爬虫）
5、referer: 当前页面是从哪个页面跳转过来的;
6、location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问;
7、Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能
状态码
我们通常在网页中的404，它其实就是状态码。状态码通常也是约定俗成、认为规定的。通常，状态码和状态码的含义有如下的对应关系：
解释一些4xx和5xx：
4xx表示资源找不到，但这个是客户端的锅，客户端找的资源压根不合理
而5xx资源找不到的原因是因为服务器崩了，这个锅是服务器的。
注意一下二者的区别。
通常的，像200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)
我们现在来尝试抓一个http包：
我们用Fiddler来进行抓包：
如上图，是我在访问baidu.com的时候，抓的https的报文。
依照着改图，我们再来补充一些知识。
首先注意里面有一个 keep-alive，表示长链接（close表示短链接）。
可不是说http是无连接的吗？注意，再次强调，我们链接的打开与关闭，是由我们自己控制，http的无连接，是指http发送一个request，然后再拿回来一个resonpse就完了。而底层的tcp链接要不要关闭是取决于http协议的，http复用了这个链接，选择长连接或者短链接。
注意到上面还有一行，是用来发送自己的平台信息和浏览器等相关的信息（这就解释了为什么我们平时在安装软件的时候，浏览器能够自动识别我们的电脑相关的信息（比如是x64平台，win版本））
还有一行cookie。
我们知道，http是无状态的，所以需要我们登录才能访问的有很多场景，可是，我们在实际中发现浏览器好像能够有一定的记忆，记得我的信息，可是http本身是无状态的，这又怎么解释呢？
HTTP本身是无状态的不错，但是HTTP是给用户用的，如果无状态，就会给用户造成很差的用户体验。那怎么办呢？
Cookie
先说cookie是什么。
本质上，cookie就是一个文件。
保存在本地的文件（当然也有内存级的cookie）。那么每一次，在request当中，有一个cookie作为value值发出去了，在response中，有一个set-cookie。这个cookie是客户端向服务器发，而set-cookie指服务器向客户端写入的内容（实际上是一种文件）
(如下图)
那么cookie的作用，就是我只要输入了一次，后续我就不用再输入啦，这样会给予用户比较良好的用户体验。
举一个简单的例子：
当我们的http请求去访问服务器的时候，服务器是能够拿到我们的账号和密码的。而服务器是要给我们的客户端一个response，那么在这个response当中，服务器就会以set-cookie的方式，将我们的账号和密码返回给客户端，客户端就会以cookie的形式保存到浏览器中。而cookie的本质是浏览器的一种文件。
从此往后，在一段特定的时间内，客户端在下一次http请求的时候，会在request里自动将cookie里携带的信息以key:value的形式发送给服务器。这样，服务器就够能拿到我们的账号密码，就不需要用户自动输入了。
（当然，如果我们清理掉我们的cookie，那就要重新输入了）
注意：这里的cookie分为内存级的和硬盘级的。
那如果有黑客来入侵我的主机，那他岂不是能够拿到我的cookie干坏事了吗？
那怎么解决呢？
这就演变出了session
这是怎么一回事呢？
当第一次输入了账号密码的时候，在服务器端会通过这个账号密码，生成一个全网唯一的一个sid，然后将你的账号密码存储在server服务器端的一个session文件当中，然后，给用户返回的是一个sid，这个sid将会以set-cookie : sid = XXX的形式返回，然后下一次客户端再来访问的时候，直接拿着这个sid来访问，服务器端通过这个sid来去找到对应的session文件当中对应的账户是否处于登录状态，如果是，那就算是登录成功了。
这个时候，即使黑客拿，也只能拿到我的sid，却什么也做不了。最多代替我进行访问，可是我的账号密码信息并未泄露。
好啦，本节的内容我们就到这里啦，在下一节，我们将会为大家来解释http和https之间的关系。
798
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
