快速掌握前端的HTTP基础(1)
来源:互联网 发布:常任理事国知乎 编辑:程序博客网 时间:2024/05/18 03:29
事务
一个HTTP事务由一条(客户端发往服务器)的请求命令和一个(服务器发回客户端)的响应结果组成。
HTTP使用术语流入(inbound)和流出(outbound)来描述事务处理。
报文
HTTP报文是由一行行的键值对字符串组成的,HTTP报文都是纯文本,不是二进制代码,所以可以很方便进行读写。报文可以分为请求报文和响应报文。报文由三个部分组成,对报文进行描述的起始行(start line),包含属性的首部(header)块,以及包含数据的主体(body)块。
起始行: HTTP/1.0 200 OK //OK这里是解释性原因短语 首部: Content-type: text/plain Content-length: 19 主体: message...
状态码
- Status 1xx(临时响应) 表示临时响应并需要请求者继续操作
- Status 2xx(成功)
- Status 3xx(重定向) 一般用来重定向
- Status 4xx(请求错误) 请求出错
- Status 5xx(服务器错误)
状态码用来告知客户端请求状态,伴随着状态码,HTTP还会发送一条解释性的原因短语
接下来是几个常见的状态码,200就不说了。
301是永久性转移,响应的Location首部中应该包含资源现在所处的URL
302是暂时性转移,但是客户端应该使用Location首部给出的URL来临时定位资源,将来的请求仍应使用老的URL,301比302更有利于SEO。
304是上次请求后,使用缓存资源。(下面会详细讲到)如果在chrome devtools中发现某静态资源的状态码是304,需要强制刷新浏览器。401是请求需要身份验证。403服务器拒绝请求。
请求方法
请求方法不止是GET和POST,常用的还有PUT和DELETE,这四个请求方式分别对应查,改,增,删。
HEAD方法与GET方法的行为类似,但服务器在响应中只返回首部,不会返回主体部分。使用HEAD,可以查看响应中的状态码,看某个对象是否存在,通过查看首部,测试资源是否被修改。
客户端发起请求时,这个请求可能要穿过防火墙,代理,网关等其他应用程序,每个中间节点都可能修改原始的HTTP请求,TRACE方法允许客户端在最终将请求发送给服务器时,看看它变成什么样子。TRACE请求会在目地服务器端发起一个“环回”诊断。形成最后一站的服务器会弹回一条TRACE响应,并在响应主体中携带它收到的原始请求报文(以TRACE开头)。TRACE请求有其缺点,比如代理可能将POST请求直接发送给服务器,而将GET请求发送给另一个HTTP应用程序(比如Web缓存)
OPTIONS方法请求Web服务器告知其支持的各种功能,可以询问服务器通常支持哪些方法(比如在跨域中会先发一个OPTIONS请求,这个请求不带cookie)
会话
http是无状态协议,那么它怎么保存用户的会话状态?首先会话状态是什么,打个比方,A和B隔着门聊天,这时C也在附近,A怎么确定和他说话的是B还是C,这就用到了会话,会话是A和B的聊天状态。B和A开始说话前,B把自己的贴身信物扔给了A,这个贴身信物是唯一,能确认是B的。这时A开启一次会话,并且把自己的话筒给了B,B拿着话筒就可以不断对A说话。因为C没有话筒,所以可以判断是谁在说话。等到B说完的时候,表明想关闭会话,那么A就知道B已经停止对他说话,把会话关闭,让B把话筒扔了。那么B扔的贴身信物就是我们平时常用的会员登录或者其他身份验证,B的浏览器发送了表明自己身份的请求,服务器知道这是用户B之后开启了一次session,并把这次会话也就是session的标识,通过cookie记录在B的浏览器上,每次B发送请求的时候带上了cookie,也就是拿着’话筒’说话。说完之后,B关闭浏览器,那么cookie消失,话筒没了,或者B选择登出,那么服务器A将cookie删掉,’话筒’也没了,会话都将结束。
那么没有cookie能不能进行会话呢,在用户B禁用了cookie之后,可以通过url记录会话信息,服务器通过改变B的url参数,使B的浏览器请求获得了’话筒’,这时候url就变成了这样: http ://www.xx.com?session_id = xx134x。
cookie
cookie在设置时需要在参数中指明过期时间,如果没指明,就没有过期时间。所以cookie的存储分为两种:1.持久cookie,数据保存在磁盘中 2.会话cookie, 数据保存在内存中,浏览器关闭后将被清除。上文中说到的cookie就属于第二种。
Expires与Cache-Control
Expires与Cache-Control就是服务器用来约定和客户端的缓存有效时间的。
Response-Headers Cache-Control: public, max-age=2600 Date: ... Expires: Wed,29 Jan 2017 08:39:13 GMT
比如上面这个响应头,Expires(HTTP1.0)规定了缓存失效的时间,Date为当前时间,而Cache-control的max-age(HTTP1.1)规定了缓存有效时间(2600s),唯一的区别是Expires要求客户端和服务器的时钟完全一致,而max-age则没有这个限制。 是在当前页面按下ctrl + r会默认跳过max-age和Expires的检验直接向服务器发送请求。和其他expire一样,可以将其设置为过去的一个时间来禁止缓存。
last-Modified/if-Modified-Since
在浏览器第一次请求某一个URL时,服务器端的返回状态会是200,内容是你请求的资源,同时有一个Last-Modified的属性标记此文件在服务器端最后被修改的时间
Response Headers Last-Modified:Wed,29 Jan 2017 08:39:13 GMT
当在缓存期内时,要通过按下ctrl + r会默认跳过max-age和Expires的检验直接向服务器发送请求。这时请求上会带有
Request Headers If-Modified-Since: Wed,29 Jan 2017 08:39:13 GMT
这个值与上次相应中Last-Modified完全一致,服务器将这个数值与服务端最后修改时间对比,如果相同,则响应304,从缓存读数据,否则响应200,同时通过响应头更新Last-Modified的值
Etag/if-None-Match
Etag/if-None-Match和上面的方式一样,也要配合Cache-Control使用。实际上Etag不是文件的版本号,而是一串可以代表该文件唯一的字符串,(Apache中,ETag的值,默认是对文件的索引节,大小和最后修改时间得到的一个hash值)。对比Etag值的比对比时间戳的好处在于
1. 时间戳精确到秒,也许一秒内文件被修改了多次,而Etag唯一
2. 如果某些文件会定期生成,除了时间之外没有其他变化,但Last-Modified却改变了,导致文件无法使用缓存
3. 有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致的情况
不能缓存的请求
- HTTP信息头包含Cache-Control:no-cache等等服务器告诉浏览器不用缓存的请求
- 需要根据Cookie,认证信息决定输入内容的动态请求不能被缓存
- 经过HTTPS安全加密的请求
- POST请求无法被缓存
TCP连接和端口号
在TCP中,需要知道服务器的IP地址,以及服务器上运行特定软件的TCP端口号。
//使用了机器的IP地址 http://207.200.83.29:80/index.html http://www.netscape.com:80/index.html //没有时默认80,https为443 http://www.netscape.com/index.html
TCP连接是基于文本的
三次握手
TCP协议采用三次握手策略,发送端首先发送一个带SYN标志的数据包给对方,接收端收到后,回传一个带有SYN/ACK标志的数据包以传达确认信息,最后,发送端再回传一个ACK标志的数据包,代表握手结束。若在握手某个阶段中断,TCP协议会再次以相同顺序发送相同数据包。为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手,为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。断开一个TCP连接需要四次挥手(通过FIN包)
代理
代理位于客户端和服务器之间,接收所有客户端的HTTP请求,经过部分处理后转发给服务器。
Agent代理
用户Agent代理是代表用户发起HTTP请求的客户端程序,所有发布Web请求的应用程序都是HTTP Agent代理,Web浏览器就是一种Agent代理机制,除此之外还有爬虫等。
HTTPS更安全
因为网络请求需要中间有很多服务器路由器的转发,中间的节点都可能篡改信息,HTTPS之所以更安全,是因为它利用ssl/tls协议传输,保障了传输过程的安全性,加密原理请参考HTTPS为什么更安全
IE缓存问题
在IE8浏览器下,如果ajax请求的方法是GET,并且请求的URL不变,那么这个请求的结果就会被缓存。解决的方法是在URL加上时间戳参数等
图片缓存
当我们想在PC端用几个稍微大点的图片做动画,可以在网页create一个img节点,让这个img元素的src指向这些图片的地址。等到想使用这个图片的时候,浏览器中已经有对此路径的缓存了,这样就避免了页面卡顿。当然,如果用户设置了disable-cache,这个方法就失效了
TCP和UDP区别
TCP传输协议是基于连接的传输协议,也就是在正式发送数据之前,必须和对方通过三次握手建立可靠连接。
而UDP是面向非连接的协议,直接发数据包,只适用于一次传送少量数据,对可靠性要求不高的环境
输入一个URL之后
- 浏览器开启一个线程来处理请求,对URL分析判断如果是http/https协议就按照Web方式来处理
- 调用浏览器内核的对应方法,比如WebView中的loadUrl方法
- 通过DNS解析获取网址的IP地址,设置UA等信息发出第二个GET请求
- 客户端发送请求报头
- 服务器进行相应处理
- 处理响应报头,如果确定使用缓存,则返回304,没有的话返回200
- 快速掌握前端的HTTP基础(1)
- 前端开发中快速掌握的技巧
- 前端开发中快速掌握的技巧
- 前端需要掌握的基础技术
- 学习web前端需要掌握的基础技术
- 快速掌握shell基础目录
- 前端搬运工:零基础的前端开发初学者应如何系统地学习?前端掌握技能的学习路线
- 前端需掌握的知识
- 前端应掌握的知识
- 前端基础 -- HTTP协议简述
- MySQL快速掌握之基础篇
- 快速掌握Ajax-Ajax基础实例
- 快速掌握Ajax-Ajax基础实例
- 快速掌握Ajax-Ajax基础实例
- 零基础如何快速掌握PHP语言
- 前端基础进阶(十三):透彻掌握Promise的使用,读这篇就够了
- 快速掌握一门新的语言
- 快速掌握activity的生命周期
- 七大排序算法之冒泡排序
- 一次自制腊肉的过程
- BCD转int
- C语言中的指针与数组
- ACM之LeetCode中Add Two Numbers
- 快速掌握前端的HTTP基础(1)
- 1090. Highest Price in Supply Chain (25)
- 数学分析--泰勒定理的故事
- 我的web前端自学之路-心得篇:我为什么要学习web前端?
- [SinGuLaRiTy-1000] High Percision Calculation 高精度算法集锦
- 主席树笔记
- 龟兔赛跑预测
- Java——可变长参数列表
- 中介者模式