简述

HTTP全称是超文本传输协议,它和HTML都是由一个WWW之父蒂姆·贝纳斯·李(Tim Berners-Lee)提出的。HTTP就是对客户端发送请求和服务器响应请求的一种规范格式。现在的HTTP协议分为HTTP1.0、HTTP1.1和HTTPS,他们都是属于TCP/IP协议簇的子协议。

HTTP工作流程

如果用户在浏览器输入www.tianmao.com并点击搜索,HTTP工作流程如下:

域名解析

浏览器将域名解析成计算机能识别的IP地址,一般情况下可能会存在缓存。缓存的搜索分为几种情况

  1. - 搜索浏览器自身缓存,若有,直接用这个被解析的IP地址
  2. - 若浏览器本身没有,则搜索操作系统的缓存,若有,则用这个被解析过的IP地址
  3. - 若操作系统没有,则搜索host文件
  4. - host文件没有,则向本地配置的首选DNS服务器发起域名解析请求

测试连接

这里其实就是指三次握手。
image-20210406111456353.png
发送端发起第一个数据包,可能因为某种原因,数据包丢失了,过了很久发送端没有收到任何反馈,于是又发送第二个数据包,由于发送顺利(第一次握手),接收端发了一个响应信息(第二次握手)。好巧不巧,这时候接收端收到了之前数据包,接收端还是作了响应,一会儿发送端收到了接收端的响应信息,他肯定知道这是第一个数据包发送的消息,他也知道接收端都接收了,为了让接收端清楚第二个数据包才是他最想发送的,于是又向接收端发送了一个确认帧并成功(第三次握手),接收端就知道第二个数据包才是发送端想要发送的。

发起请求

由于测试连接成功了,所以客户端可以直接将请求报文封装并发送

作出响应

服务器接收到报文并经过一系列步骤,读取请求报文和发出响应报文

浏览器解析

将服务器发来的响应报文解析成浏览器的标准格式

浏览器渲染并返回给客户端

客户端能看到的样子

HTTP报文

HTTP报文分为请求报文和响应报文,请求报文就是浏览器发送给服务器的报文,响应报文就是服务器发送给浏览器的报文,这个报文,其实就是协议,本质上是约束,是规范格式。

请求报文

格式

请求行/r/n
请求头/r/n
(空格)
请求体/r

说明

  • 请求行:由 请求方法 + 请求资源 +版本协议 组成。
    • 请求方法:包括GET,POST,OPTIONS,DELETE等
    • 这里需要主要,GET是最为常见的请求方法,一般在网址输入地址所使用的方法就是GET方法,其特点是请求参数是附着在请求资源里的,以‘?’作为分割。除了网址栏输入地址栏,还能通过表单提交里将method设为get的方式,也能看到请求方式是get;与此对应,表单提交里将method设为post的方式看到的请求方式是post,其特点是将请求体的数据不放到请求资源里。
    • get和post最重要的区别是语义,即顾名思义。而参数存放的位置,仅仅是因为浏览器的行为导致,HTTP协议里并不是这样规定的,所以要注意:眼见也不一定为实。
    • 版本协议主要是HTTP1.0和1.1,现在几乎所有的浏览器支持的都是HTTP1.1,其优点是稳定,不会因为一个请求结束就断开连接等等。
  • 请求头

请求头是对请求行的补充,由于这是请求报文,是给服务器看的,即浏览器再设置一些额外的参数告诉服务器响应的时候你应该注意些什么。比如:

  1. - Accept:浏览器可接受的
  2. - MIME类型 _/_ (大类型)/(小类型)
  3. - Accept-Charset: 浏览器通过这个头告诉服务器,它支持哪种字符集
  4. - Accept-Encoding:浏览器能够进行解码的数据编码方式,比如gzip (压缩格式)
  5. - Accept-Language: 浏览器所希望的语言种类,当服务器能够提供一种以上的语言版本时要用到。 可以在浏览器中进行设置
  6. - **Host:初始URL中的主机和端口 (每个请求报文中一定要有的)**
  7. - **Referer**:包含一个URL,用户从该URL代表的页面出发访问当前请求的页面 (防盗链)(引流)
  • 请求体

这里就是请求报文要传输的内容。

响应报文

格式

响应行/r/n
响应头/r/n
(空格)
响应体/r/n

说明

  • 响应行
    • 包括:版本协议 + 状态码 +原因描述
    • 版本协议,以HTTP1.0,此处不做赘述
    • 状态码包括200+到500+
      • 200多,表示状态是OK的,其中200表示没有任何问题
      • 300多表示重定位,302、307一定要搭配一个响应头如Location一起使用;304表示缓存是最新的
      • 400多表示资源异常。404表示客户端要请求的资源不存在。
      • 500多表示服务器异常,代码有问题
  • 响应头

与请求头对应,大体类似,只是请求头一定要包含host类型,响应头一定要包含Content-Type。之所以是这样的要求,是因为响应头是给浏览器看的,表示如果你还要向我发送请求的话应该按照什么具体格式来发送,我支持什么格式你就按照这个格式发。响应头的具体参数如下:

  1. - Location: http://www.qq.com/指示新的资源的位置 ,需要搭配302、307状态码一起来使用
  2. - Server: apache tomcat 指示服务器的类型
  3. - Content-Encoding: gzip 服务器发送的数据采用的编码类型
  4. - Content-Length: 80 告诉浏览器**响应正文**的长度
  5. - Content-Language: zh-cn服务发送的文本的语言**Content-Type**: text/html; 服务器发送的内容的MIME类型.**比如图片类型应该是image/jpeg等,但是如果你设置了text/html,那么浏览器可能就无法正常显示**
  6. - Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT文件的最后修改时间
  7. - Refresh: 1;url=http://www.qq.com指示客户端刷新频率。单位是秒。页面跳转的一个响应头
  8. - Content-Disposition: attachment; filename=aaa.zip指示客户端保存文件。如果你的响应中又这个响应头,那么浏览器会将当前资源以附件的形式下载下来。
  9. - Set-Cookie: SS=Q0=5Lb_nQ; path=/search服务器端发送的
  10. - CookieExpires: 0
  11. - Cache-Control: no-cache (1.1)
  12. - Connection: close/Keep-Alive
  13. - Date: Tue, 11 Jul 2000 18:23:51 GMT
  • 响应体

如果服务器需要将大量的数据传输给客户端,那么就把数据写入到响应体中。

服务器

手写一个简易服务器

本质

服务器本质上就是将本地硬盘资源发布到网上供别人访问。
其基本内容就是通过监听一个socket的端口号,有客户端来访问时,读入他的输入流,经过解析,给他返回一个输出流。

Tomcat

类似JDBC,我们是完全可以写一个简易服务器,但是这种服务器与市面上常见的服务器相比存在大量不足,比如在更换返回页面等。为此,HTTP规定了一个标准,服务器应该遵照什么格式提供什么样的服务。但在实际上,性能、是否免费、应用性等在市场上各种比较,Tomcat脱颖而出,占领了服务器市场上的70%以上。
即使将来由于一些原因不能再使用Tomcat再转向别的服务器,其实区别并不大,所以,要学习服务器,掌握Tomcat就够了。

下载、解压

image.pngimage.png

  • bin,包含tomcat启停的批处理命令
  • conf,配置文件,其中包含server.xml、conf\Catalina\localhost、web.xml
  • logs,日志文件,记录服务器运行的情况
  • temp,临时文件
  • webapps,服务器静态资源发布的地方,其实服务器发布的最小单位是应用
  • 其他

    发布资源

    直接发布

    webapps目录下新建一个文件夹(其表现为一个应用),在应用中可以新建一个txt、html或者其他浏览器能解析的文件都行,然后自己想发布什么资源就写点什么到文件里去。
    image.png
    ———————————————————————————————————————
    image.png

    虚拟映射

    虚拟映射就是不必将资源文件非要放到webapps目录下也能达到相同的效果,这里有两种虚拟映射的方式。
  • conf\Catalina\localhost目录下新建一个xml文件,其中文件名会覆盖掉应用名

image.png image.png

  • server.xml中找到一个host标签,在标签内新增一个Context节点

image.png image.png

组成结构

image.png
image.png

Tomcat处理HTTP请求的过程localhost/test/index.jsp:
image.png image.png
1、用户发送一个请求,被发送到当前机器的80端口号,被正在监听80端口号的coyote HTTP/1.1获得
2、Connector组件将收到的请求传递给Engine组件
3、Engine获得了请求地址为localhost/test/index.jsp,匹配虚拟主机
4、匹配到名为localhost的host,如果没匹配到,也将请求交给它处理,它被定义为Engine的默认虚拟主机,该host获得/test/index.jsp,匹配它所拥有的全部Context
5、匹配/test应用名对应的Context节点,Context节点获得index.jsp,它再去寻找响应的servlet
6、Servlet处理完逻辑
7、Context节点把执行完的结果返回给Host
8、Host将结果返回给Engine
9、Engine将结果返回给Connector组件
10、Connector将最终的响应结果返回给客户端

再以访问http://localhost:8080/temp2/hello3.txt为例

  • 浏览器地址栏输入该网址,浏览器会解析域名,拿到ip地址,生成一个HTTP请求报文
  • 借助于底层的网络设施,传输到目标机器中
  • 请求被监听着8080端口号的HTTP/1.1 Connector接收到
  • Connector需要将请求报文进行解析,然后生成一个request对象(同时还会提供一个response对象)
  • 将这两个对象传给Engine,(政策的下发)将这两个对象交给Host来处理
  • Host来选择一个合适的Context来处理

Context的来源有哪些?
1.webapps下面的应用
2.conf/catalina/localhost下面的配置
3.server.xml中配置的Context节点),发现应用中正好有一个叫做/app3的,

  • Host将request、response对象进一步交给Context(path、docBase)来处理,需要去找一个叫做hello3.txt文件

docBase + /hello3.txt ——- absolutePath———— file———inputStream——写入到response的outputStream中

缺省设置

  • 缺应用名
  • 缺资源
  • 缺端口号

演示一个以输入一个IP地址就能访问到hello3.txt的例子:
image.pngimage.png