Linux网络原理与编程（2）——第十二节 应用层协议(以HTTP为例)

目录

协议

HTTP协议

认识URL

HTTP协议的特征

HTTP的构成及报文格式

报文格式

请求方法

常见的Header

状态码

Cookie

---

我们从本节开始，就来正式地详细介绍网络各个层次的内容。

我们先从最顶端的应用层协议说起。

在说应用层协议之前，我们来思考一下什么叫协议？

协议

协议是一种 "约定". 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之间的关系。