Web与HTTP

一些术语

Web页是由一些对象组成 ,比如HTML文件、JPEG图像、音频文件等。

一个Web页有一个基本的HTML文件组成,里面放着若干对象的引用,它里面没有实际放着那些对象,只是用URL指向。

通过URL对每个对象进行引用。

URL由以下几部分组成

访问协议://用户:口令@主机名/路径名:端口

用户和口令可以不输入,即匿名访问,平常上网就是使用这种方式访问。

端口也可以不输入,一般会设置自动跳转的。


  • URL和URI的区别

    URI是统一资源标志符Uniform Resource Identifier

    URL是统一资源定位符Uniform Resource Locator

    URI可以唯一地标识一个资源,而URL重点在于Locater,提供找到某些资源的路径,在stackflow中有这么一句话:locators are also identifiers, so every URL is also a URI, but there are URIs which are not URLs.

HTTP概况

HTTP:超文本传输协议

是以请求响应的方式来通信。

客户端的形式是浏览器,而服务器就比如tomcat这些。

  • 使用TCP
    1. 客户端发起一个与服务器的TCP连接,在80号端口(建立套接字)
    2. 服务器接受客户端的TCP连接。
    3. 通过一对对的客户端和服务器的socket的连接进行通信,服务器也一直有socket在80端口等待别的
    4. 连接之后,客户端就从服务器中取数据了,如果拿的是Web页,那就继续在它的URL上拿各种网页对象,一块一块地再拼上去。
  • 无状态
    • 不维护关于客户的任何信息。简单。
    • 维护状态的协议很复杂,必须维护历史信息;如果有一边死机了,状态信息不一致;节省资源,可以支持更多的客户,比有状态服务器更优。

HTTP连接

  • 非持久HTTP(1.0)
    • 在HTTP连接前,需要下层实体一次交互才能完成,指TCP连接确认和连接确认。
    • 然后才能进行HTTP请求和HTTP响应,这样请求交互信息。
    • 最多支持一个对象在TCP上发送。
    • 交互完之后就断开,断开又涉及TCP的断开确认啥的,最后结束。
  • 持久HTTP(1.1)
    • 下层实体的连接确认与之前的一样。
    • 然后进行HTTP请求和响应,请求对象。
    • 请求完之后,不关,还有其它的请求,可以继续请求对象。
    • 支持多个对象的传输(就是请求多次)
    • 结束与之前一样。

响应时间模型

往返时间RTT(round-trip time)一个小的分组从客户端到服务器,再回到客户端的时间(传输时间忽略)

响应时间=2RTT+文件传输时间。

优缺点

  • 非持久

    • 发送每个对象需要2RTT
    • 操作系统必须为每个TCP连接分配资源
    • (而且浏览器通常打开并行TCP连接以获取引用对象)
  • 持久

    • 可以一次传输多个对象,响应后仍保持TCP连接,接下来可以通过相同连接进行传送。
    • 流水线和非流水线
      • 在前面的对象回来之后我再请求下一个对象(一次只请求一个),这是非流水线。
      • 一次性请求n个对象(不管它有没有回来),然后再接受,这是流水线。
      • 流水线方式可以节省时间,是HTTP1.1的默认方式

HTTP报文

它只有两种:请求和响应

HTTP请求报文

它是人能阅读的,以ASCLL形式展示。

首先是请求行,下面是首部行,然后一个回车符,下面就是请求实体


  • 请求行

    首先是一个命令:GETPOSTHEAD)等……

    然后是获取哪个目录的哪个文件?定位用

    最后是协议和版本号

  • 首部行

    • 主机名Host
    • 用户代理的程序User-agent
    • 连接是否关闭Connection
    • 接受语言Accept-language

    (感觉都是一些信息)

  • POST的话,可能还有一个请求实体

image-20210630000110184

个人补充:GET和POST的区别

image-20210630000201686

方法的补充
  • HEAD
    • 获取HTML的头部,与搜索引擎有关,比如一些爬虫,只要想一些title信息,而不用所有的东西,就使用HEAD
  • PUT
    • 向服务器提交一些对象,上传文件到URL字段目录
  • DELETE
    • 删除URL字段规定的文件
提交表单输入
  • POST
    • 在实体内容里面放需要向服务器提交的内容
  • URL方式

HTTP响应报文

与请求报文相似。

状态行首部行、一行空行+数据

样例如下:

image-20210630001122343

  • 状态行:协议/版本号 状态码 状态信息
  • ……

它需要应用层自己识别边界,如客户端传了两个15k的包,然后通过TCP传送到服务器中,但是服务器收到的是一个30k的包,需要服务器自己来识别这两个15k的包的边界。

常见响应状态码
  • 200 OK
    • 请求成功
  • 301 永久转移
    • 你想要请求的对象被永久的转移了,新的URL在响应报文的location中指定。
    • 客户端会自动用新的URL去获取对象
  • 400 Bad Request
    • 请求不能被服务器解读,可能是损坏了?
  • 404 找不到
  • 505 版本号不支持

用户-服务器状态:cookies

上面知道,HTTP协议是无状态协议。服务器不维护客户端的状态。

一般的网页使用这个无状态就很好,但是在一些电子商务的网站(比如tb这些?)则需要服务器需要携带客户端的数据

过程

客户端第一次向服务器发送请求的时候,通常不带cookie。

服务器发现这个客户是新来的,于是在响应报文的头部中设置,并且保留在服务器数据库。

客户端拿到cookie,也会保留在客户端的本地中。

下次客户端访问服务器的时候,会带上cookie,然后服务器查询本地的cookie,关联一下,就知道“他是谁了”。

通过这样,后续的所有操作,都能记录下来,就能使它变得有状态了。

组成

  • HTTP响应报文中有一个cookie的首部行
  • HTTP请求报文中有一个cookie的首部行
  • 在用户端中保留有一个cooki文件,由用户的浏览器管理
  • 在Web站点有一个后端数据库

(其实就是上面例子的抽象出来的)

好处
  • 用户验证
  • 购物车
  • 推荐
  • 用户状态
  • 隐私问题……

它会暴露用户的行为,然后就……哎各种信息收集,你懂的。

Web缓存(代理服务器)

目标:不访问原始服务器就能满足客户的需求。

浏览器将所有的HTTP请求发送给缓存。

  • 在缓存中的对象,直接由缓存返回
  • 不在缓存中,则缓存请求原始服务器,然后将对象返回给客户端

优点:

从客户端说,它快了,响应时间少了!

从服务器说,它负担少了。

从网络说,它减少了拥塞。

……


这里使用数据展示一一下使用缓存和不使用缓存的计算。

首先:总时延 = 发送时延 + 传播时延 + 处理时延 + 排队时延

(排队时延真可怕)

$t_排=\frac{1-I}*\frac$

带宽如果刚好满足,比如传输的带宽是1.544Mbps,传输数据的带宽是1.5Mbps,那流量强度就很大了,接近于1,那排队时延就会很长。

如果加了缓存,首先命中缓存的部分就能分散一部分流量,然后没有命中的才去原始服务器拿,这时流量强度也低了,那排队时延就没有成为时延的主要因素了。


条件GET方法

缓存服务器和原始服务器的数据有可能不一致。

目标:如果缓存中的对象没有修改,就不需要发送对象。

在头部加上:

if-modified-since,如果这个对象在这个时间后修改了,把新的对象给我吧;如果没有改变,那就不用把对象给缓存服务器了。

这样只要传个头部就行了,不用把整个对象都给他。


过程

比如,缓存服务器想知道有没有对象改变了,就发一个HTTP请求给原始服务器,并带上if-modified-since这个字段。

原始服务器会就此返回一个响应,如果修改了,就返回个304 Not Modified;否则就返回一个200,并把改变的数据发回去。

这样就能解决服务器版本和缓存版本的一致性问题。