1.http基础
声明:本文是本人 编程小翁 原创,转载请注明。
HTTP属于老话题了,在项目中我们经常需要往服务端发POST或者GET请求,但是对于HTTP的了解不应只局限于此。千里之行,始于足下。越想走的远,基本原理就应该了解的透彻全面一些,仅仅停留在使用ASIHttpRequest或者AFNetWorking传个参数发个请求的程度上是不够的。这篇文章就是带你全方面回顾一下HTTP。
通过本文你能收获哪些内容:
·完整HTTP请求与响应包含的必要元素
·HTTP不同版本之间的差异
·HTTP、Socket、TCP的区别(易混)
一、HTTP协议
HTTP本质上是一种协议,全称是Hypertext Transfer Protocol,即超文本传输协议。从名字上可以看出该协议用于规定客户端与服务端之间的传输规则,所传输的内容不局限于文本(其实可以传输任意类型的数据)。
![](https://i-blog.csdnimg.cn/blog_migrate/2a4219f109fe787a7a7f7bf1b17b5e9d.webp?x-image-process=image/format,png)
二、HTTP请求与响应的内容
当我们往服务端发送一条HTTP请求时都发送了哪些东西过去呢?
先看一个POST请求的示例图:
![](https://i-blog.csdnimg.cn/blog_migrate/7456f93dc8cf689b316b129758c800c7.webp?x-image-process=image/format,png)
注:本文使用Paw来模拟发送HTTP请求,使用Charles抓包,Charles选中"Request"以及"Raw"选项就可以看到请求的全部内容
以上示例图中其实已经包含了一个HTTP请求所必备的几大要素:请求行、请求头(headerField)、请求体(body);同理,响应也有状态行、响应头、实体内容。接下来我们逐个展开。
1、请求行
请求行包含请求方法(Method)、请求统一资源标识符(URI)、HTTP版本号,如图2.1第一行所示:
![](https://i-blog.csdnimg.cn/blog_migrate/063161e6a602612b1e7b429fffeae7d3.webp?x-image-process=image/format,png)
- 请求方法就是我们所熟悉的POST、GET、HEAD、PUT等
- URI就是URL中排除掉Host剩下的部分,也就是资源在服务器本地上的路径
- HTTP版本号,目前主流的版本是1.1(1999年开始采用),最新的版本是2.0(2015年5月发布)。不同版本之间差异下面会再展开
2、请求头
请求头主要存放对客户端想给服务端的附加信息,下图框框的部分就是请求头:
![](https://i-blog.csdnimg.cn/blog_migrate/9bb4fbd995a8e87f22300b857991fe14.webp?x-image-process=image/format,png)
HTTP请求在iOS中用NSURLRequest
与NSMutableRequest
表示;HTTP响应用NSHTTPURLResponse
表示。
- Host: 目标服务器的网络地址
- Accept: 让服务端知道客户端所能接收的数据类型,如
text/html
*/*
- Content-Type: body中的数据类型,如
application/json; charset=UTF-8
- Accept-Language: 客户端的语言环境,如
zh-cn
- Accept-Encoding: 客户端支持的数据压缩格式,如
gzip
- User-Agent: 客户端的软件环境,我们可以更改该字段为自己客户端的名字,比如
QQ music v1.11
,比如浏览器Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Maxthon/4.5.2
- Connection: keep-alive,该字段是从HTTP 1.1才开始有的,用来告诉服务端这是一个持久连接,“请服务端不要在发出响应后立即断开TCP连接”。关于该字段的更多解释将在后面的
HTTP版本简介
中展开。 - Content-Length: body的长度,如果body为空则该字段值为0。该字段一般在POST请求中才会有。
POST请求的body请求体也有可能是空的,因此POST中Content-Length也有可能为0
- Cookie: 记录者用户信息的保存在本地的用户数据,如果有会被自动附上
值得一提的是,在iOS中当你发送一个任意请求时,不管你愿不愿意,NSURLRequest都会自动帮你记录你所访问的URL上设置的cookie。在iOS中用
NSHTTPCookieStorage
表示,是一个单例。通过NSHTTPCookieStorage *cookieJar = [NSHTTPCookieStorage sharedHTTPCookieStorage];for (NSHTTPCookie *cookie in [cookieJar cookies]) { NSLog(@"%@", cookie);}
可以获取目前被自动保存的所有cookie。对cookie的操作感兴趣的请移步IOS中http请求使用cookie这篇文章。
以上就是我们日常开发中比较经常遇到的请求头,其实还有其他的field,但篇幅所限无法一一列出,想了解所有请求头请看这里请求头响应头列表。那在iOS中如何设置添加这些field呢?可以使用-[NSMutableURLRequest addValue: forHTTPHeaderField:]
方法,获取当前请求已经设置的field可以用-[NSURLRequest allHTTPHeaderFields]
。也就是我们可以通过以上接口定制我们所需要的请求头,但是有些field是不能改的,我们看一下iOS的描述:
![](https://i-blog.csdnimg.cn/blog_migrate/0977eae78759f7f8c3cd6846d48f09e4.webp?x-image-process=image/format,png)
从文档中我们可以看到,在iOS中不应当对
Authorization
Connection
Host
WWW-Authenticate
这几个header field做更改。
3、请求体
真正需要发给服务端的数据,在使用POST-multipart上传请求中请求体就是上传文件的二进制NSData类型数据;在GET请求中请求体为空;在普通的POST请求中请求体就是一些表单数据。在iOS中一般用NSURLRequest
与NSMutableURLRequest
的HTTPBody
属性表示,添加body用-[NSMutableURLRequest setHTTPBody:]
。
4、响应状态行
状态行是服务端返回给客户端的状态信息,包含HTTP版本号、状态码、状态码对应的英文名称。
以下就是典型的正确状态行:
HTTP/1.1 200 OK
这个部分需要讲的是错误码。事实上HTTP请求错误码可以根据错误码从左往右第一个数字大致分为以下几类:
1XX:信息提示。不代表成功或者失败,表示临时响应,比如100表示继续,101表示切换协议
2XX: 成功
3XX: 重定向
4XX:客户端错误,很有可能是客户端发生问题,如亲切可爱的404
表示未找到文件,说明你的URI是有问题的,服务器机子上该目录是没有该文件的;414
URI太长
5XX: 服务器错误,比如504
网关超时
错误码是不用去记的,出错了再查对应的错误码含义就行。但是知道上面的分类有助于第一时间做出大体的判断,起码你能清楚是服务端还是客户端的原因。
5、响应头与响应实体
这部分与请求部分差异不大,响应头的字field会有稍许不同,响应头中的header field同样移步请求头响应头列表。
三、HTTP版本简介
这里我把HTTP版本简单分为三类:1.1之前,1.1,2.0,针对这三类做个主要差异的介绍:
HTTP 1.1之前
- 不支持持久连接。一旦服务器对客户端发出响应就立即断开TCP连接
- 无请求头跟响应头
- 客户端的前后请求是同步的。下一个请求必须等上一个请求从服务端拿到响应后才能发出,有点类似多线程的同步机制。
HTTP 1.1(主流版本)
与1.1之前的版本相比,做了以下性能上的提升
- 增加请求头跟响应头
- 支持持久连接。客户端通过请求头中指定Connection为keep-alive告知服务端不要在完成响应后立即释放连接。HTTP是基于TCP的,在HTTP 1.1中一次TCP连接可以处理多次HTTP请求
- 客户端不同请求之间是异步的。下一个请求不必等到上一个请求回来后再发出,而可以连续发出请求,有点类似多线程的异步处理。
HTTP 2.0
本着向下兼容的原则,1.1版本有的特性2.0都具备,也使用相同的API。但是2.0将只用于https网址。由于2.0的普及还需要比较长的一段时间,这里不展开,更多新特性请参考这篇文章。
我们重点关注一下当前1.1版本所做几点改变。支持持久连接有什么好处呢?HTTP是基于TCP连接的,如果连接被频繁地启动然后断开就会花费很多资源在TCP三次握手以及四次挥手上,效率低下。以请求一个网页为例,我们知道,一个html网页上的图片资源并不是直接嵌入在网页上,而只是提供url,图片仍需要额外发HTTP 请求去下载。一个网页从请求到最终加载到本地往往需要经过过个HTTP请求。在1.1版本之前请求一个网页就需要发生多次"握手-挥手"的过程,每次连接之间相互独立;而1.1及之后的版本最少只需要一次就够。
再来就是请求异步,其好处参考多线程异步处理,在此不展开。
以上特性可以用图2.3表示:
![](https://i-blog.csdnimg.cn/blog_migrate/6f3b4fa1256f2e3c2ff2f9ab8b9beaf3.webp?x-image-process=image/format,png)
我们可以看到:1、N次请求其实只建立了1次TCP连接,2、N次请求连续异步发出。
四、HTTP、Socket、TCP的区别
这三个概念经常被谈到,也是比较容易被混掉的概念。在回顾之前我们先看一下这三者在TCP/IP协议族中的位置关系:
![](https://i-blog.csdnimg.cn/blog_migrate/cbe357df65ca05f6d3585c1996e0fa71.webp?x-image-process=image/format,png)
HTTP是应用层的协议,更靠近用户端;TCP是传输层的协议;而socket是从传输层上抽象出来的一个抽象层,本质是接口。所以本质上三种还是很好区分的。尽管如此,有时候你可能会懵逼,HTTP连接、TCP连接、socket连接有什么区别?好吧,如果上面的图解释的还是不够清楚的话,我们继续往下看。
1、TCP连接与HTTP连接的区别
上文提过,HTTP是基于TCP的,客户端往服务端发送一个HTTP请求时第一步就是要建立与服务端的TCP连接,也就是先三次握手,“你好,你好,你好”。从HTTP 1.1开始支持持久连接,也就是一次TCP连接可以发送多次的HTTP请求。
小总结:HTTP基于TCP
2、TCP连接与Socket连接的区别
在图4.1中我们提到,socket层只是在TCP/UDP传输层上做的一个抽象接口层,因此一个socket连接可以基于TCP,也有可能基于UDP。基于TCP协议的socket连接同样需要通过三次握手建立连接,是可靠的;基于UDP协议的socket连接不需要建立连接的过程,不过对方能不能收到都会发送过去,是不可靠的,大多数的即时通讯IM都是后者。
小总结:Socket也可以基于TCP
3、HTTP连接与Socket连接的区别
区分这两个概念是比较有意义的,毕竟TCP看不见摸不着,HTTP与Socket是实实在在能用到的。
- HTTP是短连接,Socket(基于TCP协议的)是长连接。尽管HTTP1.1开始支持持久连接,但仍无法保证始终连接。而Socket连接一旦建立TCP三次握手,除非一方主动断开,否则连接状态一直保持。
- HTTP连接服务端无法主动发消息,Socket连接双方请求的发送先后限制。这点就比较重要了,因为它将决定二者分别适合应用在什么场景下。HTTP采用“请求-响应”机制,在客户端还没发送消息给服务端前,服务端无法推送消息给客户端。必须满足客户端发送消息在前,服务端回复在后。Socket连接双方类似peer2peer的关系,一方随时可以向另一方喊话。
4、问题来了:什么时候该用HTTP,什么时候该用socket
这个问题的提出是很自然而然的。当你接到一个与另一方的网络通讯需求,自然会考虑用HTTP还是用Socket。
- 用HTTP的情况:双方不需要时刻保持连接在线,比如客户端资源的获取、文件上传等
- 用Socket的情况:大部分即时通讯应用(QQ、微信)、聊天室、苹果APNs等
在iOS中,发HTTP请求一般用原生的NSURLConnection
、NSURLSession
或者开源的AFNetWorking(推荐)
、ASIHttpRequest(已停止更新)
。连接Socket连接我用的比较多是robbiehanson大神的CocoaAsyncSocket (XMPPFramework
也是出自他手)。
五、The end
以上就是关于HTTP相关概念的回顾,适合菜鸟也适合有经验同学一起回顾。
欢迎留言,如果写的不对的地方还请不吝指出。
2.http状态码
一、HTTP状态码
如果某项请求发送到您的服务器要求显示您网站上的某个网页(例如,用户通过浏览器访问您的网页或 Googlebot 抓取网页时),服务器将会返回 HTTP 状态代码以响应请求。
此状态代码提供关于请求状态的信息, 告诉 Googlebot 关于您的网站和请求的网页的信息。
一些常见的状态代码包括:
- 200 – 服务器成功返回网页
- 404 – 请求的网页不存在
- 503 – 服务器暂时不可用
下面提供 HTTP 状态代码的完整列表。 点击链接可了解详情。 您也可以访问有关 HTTP 状态代码的 W3C 网页以获得更多信息 。
1xx:请求收到,继续处理
2xx:操作成功收到,分析、接受
3xx:完成此请求必须进一步处理
4xx:请求包含一个错误语法或不能完成
5xx:服务器执行一个完全有效请求失败
1xx (临时响应)
表示临时响应并需要请求者继续执行操作的状态代码。
代码 说明
100(继续) | 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。 |
101(切换协议) | 请求者已要求服务器切换协议,服务器已确认并准备切换。 |
2xx (成功)
表示服务器成功处理了请求的状态代码。
代码 说明
200(成功) | 服务器已成功处理了请求。 通常,这表示服务器提供了请求的网页。 如果针对您的 robots.txt 文件显示此状态,则表示 Googlebot 已成功检索到该文件。 |
201(已创建) | 请求成功并且服务器创建了新的资源。 |
202(已接受) | 服务器已接受请求,但尚未处理。 |
203(非授权信息) | 服务器已成功处理了请求,但返回的信息可能来自另一来源。 |
204(无内容) | 服务器成功处理了请求,但没有返回任何内容。 |
205(重置内容) | 服务器成功处理了请求,但没有返回任何内容。 与 204 响应不同,此响应要求请求者重置文档视图(例如,清除表单内容以输入新内容)。 |
206(部分内容) | 服务器成功处理了部分 GET 请求。 |
3xx (重定向)
要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。 Google 建议您在每次请求中使用重定向不要超过 5 次。 您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。 诊断 下的网 络抓取 页面列出了由于重定向错误而导致 Googlebot 无法抓取的网址。
代码 说明
300(多种选择) | 针对请求,服务器可执行多种操作。 服务器可根据请求者(用户代理)选择一项操作,或提供操作列表供请求者选择。 |
301(永久移动) | 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。 您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。 |
302(暂时移动) | 服 务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。 此代码与响应 GET 或 HEAD 请求的 301 代码类似,会自动将请求者转到不同的位置,但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动,因为 Googlebot 会继续抓取原有位置并编入索引。 |
303(查看其他位置) | 请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。 对于除 HEAD 之外的所有请求,服务器会自动转到其他位置。 |
304(未修改) | 自从上次请求后,请求的网页未修改过。服务器返回此响应时,不会返回网页内容。如果网页自请求者上次请求后再也没有更改 过,您应当将服务器配置为返回此响应(称为 If-Modified-Since HTTP 标头)。 由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过,因此可节省带宽和开销 。 |
305(使用代理) | 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理。 |
307(暂时重定向) | 服 务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。 此代码与响应 GET 和 HEAD 请求的 301 代码类似,会自动将请求者转到不同的位置,但您不应使用此代码来告诉 Googlebot 某个页面或网站已经移动,因为 Googlebot 会继续抓取原有位置并编入索引。 |
4xx(请求错误)
这些状态代码表示请求可能出错,妨碍了服务器的处理。
代码 说明
400(错误请求) | 服务器不理解请求的语法。 |
401(未授权) | 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。 |
403(禁止) | 服务器拒绝请求。 如果您看到 Googlebot 在尝试抓取您网站上的有效网页时收到此状态代码(可以在 Google 网站管理员工具诊 断 下的网络抓取 页面上看到此信息),可能是您的服务器或主机拒绝 Googlebot 访问。 |
404(未找到) | 服务器找不到请求的网页。 例如,如果请求服务器上不存在的网页,服务器通常会返回此代码。如果您的网站上没有 robots.txt 文件,而您在 Google 网站管理员工具”诊断”标签的 robots.txt 页 上看到此状态,那么这是正确的状态。 但是,如果您有 robots.txt 文件而又看到此状态,则说明您的 robots.txt 文件可能命名错误或位于错误的位置 (该文件应当位于顶级域名,名为 robots.txt)。 如果您看到有关 Googlebot 尝试抓取的网址的此状态(在”诊断”标签的 HTTP 错误页上),则表示 Googlebot 追踪的可能是另一个页面的无效链接(是旧链接或输入有误的链接)。 |
405(禁用的方法) | 禁用请求中指定的方法。 |
406(不可接受) | 无法使用请求的内容特性响应请求的网页。 |
407(需要代理授权) | 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理。 如果服务器返回此响应,还会指明请求者应当使用的代理。 |
408(请求超时) | 服务器等候请求时发生超时。 |
409(冲突) | 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。 服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码,同时会附上两个请求的差异列表。 |
410(已删除) | 如果请求的资源已永久删除,服务器就会返回此响应。 该代码与 404(未找到)代码相似,但在资源以前存在而现在不存在的情况下,有时会用来替代 404 代码。 如果资源已永久删除,您应当使用 301 指定资源的新位置。 |
411(需要有效长度) | 服务器不接受不含有效内容长度标头字段的请求。 |
412(未满足前提条件) | 服务器未满足请求者在请求中设置的其中一个前提条件。 |
413(请求实体过大) | 服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。 |
414(请求的 URI 过长) | 请求的 URI(通常为网址)过长,服务器无法处理。 |
415(不支持的媒体类型) | 请求的格式不受请求页面的支持。 |
416(请求范围不符合要求) | 如果页面无法提供请求的范围,则服务器会返回此状态代码。 |
417(未满足期望要求) | 服务器未满足”期望”请求标头字段的要求。 |
5xx (服务器错误)
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误,而不是请求出错。
代码 说明
500(服务器内部错误) | 服务器遇到错误,无法完成请求。 |
501(尚未实施) | 服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码。 |
502(错误网关) | 服务器充当网关或代理,从上游服务器收到无效响应。 |
503(服务不可用) | 服务器目前无法使用(由于超载或停机维护)。 通常,这只是暂时状态。 |
504(网关超时) | 服务器充当网关或代理,但没有及时从上游服务器收到请求。 |
505(HTTP 版本不受支持) | 服务器不支持请求中所用的 HTTP 协议版本。 |
英文版:
100:Continue
101:Switching Protocols
102:Processing
200:OK
201:Created
202:Accepted
203:Non-Authoriative Information
204:No Content
205:Reset Content
206:Partial Content
207:Multi-Status
300:Multiple Choices
301:Moved Permanently
302:Found
303:See Other
304:Not Modified
305:Use Proxy
306:(Unused)
307:Temporary Redirect
400:Bad Request
401:Unauthorized
402:Payment Granted
403:Forbidden
404:File Not Found
405:Method Not Allowed
406:Not Acceptable
407:Proxy Authentication Required
408:Request Time-out
409:Conflict
410:Gone
411:Length Required
412:Precondition Failed
413:Request Entity Too Large
414:Request-URI Too Large
415:Unsupported Media Type
416:Requested range not satisfiable
417:Expectation Failed
422:Unprocessable Entity
423:Locked
424:Failed Dependency
500:Internal Server Error
501:Not Implemented
502:Bad Gateway
503:Service Unavailable
504:Gateway Timeout
505:HTTP Version Not Supported
507:Insufficient Storage
200号状态码
220.181.32.30 - - [02/Sep/2008:00:01:23 +0800] "GET /article/0572/72570.shtml HTTP/1.1" 200 28361 "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"
服务器日志中的200表示使用GET传递方式网页72570.shtml下载成功。即:当用户或爬虫程序向网站服务器发出浏览请求时,服务器返回 HTTP 数据流里包含某种状态码,200响应号即状态码中的一种,表示本网页被成功下载。
301号状态码
220.181.32.30 - - [02/Sep/2008:00:01:31 +0800] "GET /my/view.php?aid=14183 HTTP/1.1" 301 - "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"
服务器日志中的301表示使用GET传递方式动态网页aid=14183成功跳转。即:当用户或爬虫程序向网站服务器发出浏览请求时,服务器返回 HTTP 数据流包含某种状态码,301 重定向即状态码中的一种,表示本网页永久性转移到另一个地址。实际操作中我们可以将多个域名指向同一个网址,这也是搜索引擎唯一认可的一种网站转向的方式。
二、404状态码
220.181.32.30 - - [02/Sep/2008:00:01:51 +0800] "GET /writing HTTP/1.1" 404 4459 "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"
出现404状态码就证 明有URL地址的网页浏览不到。很多时候由于网站的改版,使很多旧版网站url地址失效。这是你需要建立404状态页来保证你网站通畅,能够达到一种回路 的效果。切记404状态页需要单独设计,不能直接在服务器端直接跳转回首页。否则,搜索引擎会大量抓取网站首页失误当成404页处理。
对HTTP404状态码的深度理解
HTTP 404 错误意味着链接指向的网页不存在,即原始网页的URL失效,这种情况经常会发生,很难避免,比如说:网页URL生成规则改变、网页文件更名或移动位置、导 入链接拼写错误等,导致原来的URL地址无法访问;当Web 服务器接到类似请求时,会返回一个404 状态码,告诉浏览器要请求的资源并不存在。但是,Web服务器默认的404错误页面,无论Apache还是IIS,均十分简陋、呆板且对用户不友好,无法 给用户提供必要的信息以获取更多线索,无疑这会造成用户的流失。
因此,很多网站均使用自定义404错误的方式以提供用户体验避免用户流失。一般而言,自定义404页面通用的做法是在页面中放置网站快速导航链接、搜索框以及网站提供的特色服务,这样可以有效的帮助用户访问站点并获取需要的信息。
HTTP404对SEO的影响
自 定义404错误页面是提供用户体验的很好的做法,但在应用过程中往往并未注意到对搜索引擎的影响,譬如:错误的服务器端配置导致返回“200”状态码或自 定义404错误页面使用Meta Refresh导致返回“302”状态码。正确设置的自定义404错误页面,不仅应当能够正确地显示,同时,应该返回“404”错误代码,而不是 “200”或“302”。虽然对访问的用户而言,HTTP状态码究竟是“404”还是“200”来说并没有什么区别,但对搜索引擎而言,这则是相当重要 的。
1.自定义404错误页返回“200”状态码
当搜索引擎蜘蛛在请求某个URL地址得到“404”状态回应时,即知道该 URL地址已经失效,便不再索引该网页,并向数据中心反馈将该URL地址表示的网页从索引数据库中删除,当然,删除过程有可能需要很长时间;而当搜索引擎 得到“200”状态回应时,则会认为该url地址是有效的,便会去索引,并会将其收录到索引数据库,这样的结果便是这两个不同的url地址具有完全相同的 内容:自定义404错误页面的内容,这会导致出现复制网页问题。对搜索引擎而言,特别是Google,不但很难获得信任指数TrustRank,也会大大 降低Google对网站质量的评定。
在使用Google Sitemap,当提交XML格式网站地图文件时,谷歌管理员工具会验证网站的身份以确保是网站合法的管理者。验证方式有两种:上传指定名称的html页 到网站根目录或者在网页meta区域添加一个标识身份的meta标签。通常是使用上传html网页的方式,但谷歌管理员工具却提示网站根目录下找不到这个 网页,这是一个很可怕的问题。
2.自定义404错误页使用Meta Refresh返回“302”状态码
常常看到许多网站的 自定义404错误页面采取类似这样的形式:首先显示一段错误信息,然后,通过Meta Refresh将页面跳转到网站首页、网页地图或其他类似页。根据具体实现方式不同,这类404页面可能返回“200”状态码,也可能返回“302”,但 不论哪种,从SEO技术角度看,均不是一种合适的选择。
对“200”状态的情况我们上面已经谈过,那么,当404页面返回“302”时,搜 索引擎会怎么对待呢?从理论上说,对“302”错误,搜索引擎认为该网页是存在的,只不过临时改变了地址,仍然会索引收录该页,这样,同样会出现类似于 “200”状态码时的重复文本问题;其次,以谷歌为代表的主流搜索引擎对302重定向的适用范围要求越来越严格,这类不当使用302重定向的情况存在很大 的风险。
确保自定义404错误页面能够返回“404”状态码
在自定义404错误页面设置完毕后,一定要检查一下其是不是能够正确地返回“404”状态码。可以使用Server Header检查工具,输入一个不存在网页的url,查看一下HTTP Header的返回情况,确信其返回的是“404 Not found”。
声明:本文是本人 编程小翁 原创,转载请注明。
HTTP属于老话题了,在项目中我们经常需要往服务端发POST或者GET请求,但是对于HTTP的了解不应只局限于此。千里之行,始于足下。越想走的远,基本原理就应该了解的透彻全面一些,仅仅停留在使用ASIHttpRequest或者AFNetWorking传个参数发个请求的程度上是不够的。这篇文章就是带你全方面回顾一下HTTP。
通过本文你能收获哪些内容:
·完整HTTP请求与响应包含的必要元素
·HTTP不同版本之间的差异
·HTTP、Socket、TCP的区别(易混)
一、HTTP协议
HTTP本质上是一种协议,全称是Hypertext Transfer Protocol,即超文本传输协议。从名字上可以看出该协议用于规定客户端与服务端之间的传输规则,所传输的内容不局限于文本(其实可以传输任意类型的数据)。
![](https://i-blog.csdnimg.cn/blog_migrate/2a4219f109fe787a7a7f7bf1b17b5e9d.webp?x-image-process=image/format,png)
二、HTTP请求与响应的内容
当我们往服务端发送一条HTTP请求时都发送了哪些东西过去呢?
先看一个POST请求的示例图:
![](https://i-blog.csdnimg.cn/blog_migrate/7456f93dc8cf689b316b129758c800c7.webp?x-image-process=image/format,png)
注:本文使用Paw来模拟发送HTTP请求,使用Charles抓包,Charles选中"Request"以及"Raw"选项就可以看到请求的全部内容
以上示例图中其实已经包含了一个HTTP请求所必备的几大要素:请求行、请求头(headerField)、请求体(body);同理,响应也有状态行、响应头、实体内容。接下来我们逐个展开。
1、请求行
请求行包含请求方法(Method)、请求统一资源标识符(URI)、HTTP版本号,如图2.1第一行所示:
![](https://i-blog.csdnimg.cn/blog_migrate/063161e6a602612b1e7b429fffeae7d3.webp?x-image-process=image/format,png)
- 请求方法就是我们所熟悉的POST、GET、HEAD、PUT等
- URI就是URL中排除掉Host剩下的部分,也就是资源在服务器本地上的路径
- HTTP版本号,目前主流的版本是1.1(1999年开始采用),最新的版本是2.0(2015年5月发布)。不同版本之间差异下面会再展开
2、请求头
请求头主要存放对客户端想给服务端的附加信息,下图框框的部分就是请求头:
![](https://i-blog.csdnimg.cn/blog_migrate/9bb4fbd995a8e87f22300b857991fe14.webp?x-image-process=image/format,png)
HTTP请求在iOS中用NSURLRequest
与NSMutableRequest
表示;HTTP响应用NSHTTPURLResponse
表示。
- Host: 目标服务器的网络地址
- Accept: 让服务端知道客户端所能接收的数据类型,如
text/html
*/*
- Content-Type: body中的数据类型,如
application/json; charset=UTF-8
- Accept-Language: 客户端的语言环境,如
zh-cn
- Accept-Encoding: 客户端支持的数据压缩格式,如
gzip
- User-Agent: 客户端的软件环境,我们可以更改该字段为自己客户端的名字,比如
QQ music v1.11
,比如浏览器Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Maxthon/4.5.2
- Connection: keep-alive,该字段是从HTTP 1.1才开始有的,用来告诉服务端这是一个持久连接,“请服务端不要在发出响应后立即断开TCP连接”。关于该字段的更多解释将在后面的
HTTP版本简介
中展开。 - Content-Length: body的长度,如果body为空则该字段值为0。该字段一般在POST请求中才会有。
POST请求的body请求体也有可能是空的,因此POST中Content-Length也有可能为0
- Cookie: 记录者用户信息的保存在本地的用户数据,如果有会被自动附上
值得一提的是,在iOS中当你发送一个任意请求时,不管你愿不愿意,NSURLRequest都会自动帮你记录你所访问的URL上设置的cookie。在iOS中用
NSHTTPCookieStorage
表示,是一个单例。通过NSHTTPCookieStorage *cookieJar = [NSHTTPCookieStorage sharedHTTPCookieStorage];for (NSHTTPCookie *cookie in [cookieJar cookies]) { NSLog(@"%@", cookie);}
可以获取目前被自动保存的所有cookie。对cookie的操作感兴趣的请移步IOS中http请求使用cookie这篇文章。
以上就是我们日常开发中比较经常遇到的请求头,其实还有其他的field,但篇幅所限无法一一列出,想了解所有请求头请看这里请求头响应头列表。那在iOS中如何设置添加这些field呢?可以使用-[NSMutableURLRequest addValue: forHTTPHeaderField:]
方法,获取当前请求已经设置的field可以用-[NSURLRequest allHTTPHeaderFields]
。也就是我们可以通过以上接口定制我们所需要的请求头,但是有些field是不能改的,我们看一下iOS的描述:
![](https://i-blog.csdnimg.cn/blog_migrate/0977eae78759f7f8c3cd6846d48f09e4.webp?x-image-process=image/format,png)
从文档中我们可以看到,在iOS中不应当对
Authorization
Connection
Host
WWW-Authenticate
这几个header field做更改。
3、请求体
真正需要发给服务端的数据,在使用POST-multipart上传请求中请求体就是上传文件的二进制NSData类型数据;在GET请求中请求体为空;在普通的POST请求中请求体就是一些表单数据。在iOS中一般用NSURLRequest
与NSMutableURLRequest
的HTTPBody
属性表示,添加body用-[NSMutableURLRequest setHTTPBody:]
。
4、响应状态行
状态行是服务端返回给客户端的状态信息,包含HTTP版本号、状态码、状态码对应的英文名称。
以下就是典型的正确状态行:
HTTP/1.1 200 OK
这个部分需要讲的是错误码。事实上HTTP请求错误码可以根据错误码从左往右第一个数字大致分为以下几类:
1XX:信息提示。不代表成功或者失败,表示临时响应,比如100表示继续,101表示切换协议
2XX: 成功
3XX: 重定向
4XX:客户端错误,很有可能是客户端发生问题,如亲切可爱的404
表示未找到文件,说明你的URI是有问题的,服务器机子上该目录是没有该文件的;414
URI太长
5XX: 服务器错误,比如504
网关超时
错误码是不用去记的,出错了再查对应的错误码含义就行。但是知道上面的分类有助于第一时间做出大体的判断,起码你能清楚是服务端还是客户端的原因。
5、响应头与响应实体
这部分与请求部分差异不大,响应头的字field会有稍许不同,响应头中的header field同样移步请求头响应头列表。
三、HTTP版本简介
这里我把HTTP版本简单分为三类:1.1之前,1.1,2.0,针对这三类做个主要差异的介绍:
HTTP 1.1之前
- 不支持持久连接。一旦服务器对客户端发出响应就立即断开TCP连接
- 无请求头跟响应头
- 客户端的前后请求是同步的。下一个请求必须等上一个请求从服务端拿到响应后才能发出,有点类似多线程的同步机制。
HTTP 1.1(主流版本)
与1.1之前的版本相比,做了以下性能上的提升
- 增加请求头跟响应头
- 支持持久连接。客户端通过请求头中指定Connection为keep-alive告知服务端不要在完成响应后立即释放连接。HTTP是基于TCP的,在HTTP 1.1中一次TCP连接可以处理多次HTTP请求
- 客户端不同请求之间是异步的。下一个请求不必等到上一个请求回来后再发出,而可以连续发出请求,有点类似多线程的异步处理。
HTTP 2.0
本着向下兼容的原则,1.1版本有的特性2.0都具备,也使用相同的API。但是2.0将只用于https网址。由于2.0的普及还需要比较长的一段时间,这里不展开,更多新特性请参考这篇文章。
我们重点关注一下当前1.1版本所做几点改变。支持持久连接有什么好处呢?HTTP是基于TCP连接的,如果连接被频繁地启动然后断开就会花费很多资源在TCP三次握手以及四次挥手上,效率低下。以请求一个网页为例,我们知道,一个html网页上的图片资源并不是直接嵌入在网页上,而只是提供url,图片仍需要额外发HTTP 请求去下载。一个网页从请求到最终加载到本地往往需要经过过个HTTP请求。在1.1版本之前请求一个网页就需要发生多次"握手-挥手"的过程,每次连接之间相互独立;而1.1及之后的版本最少只需要一次就够。
再来就是请求异步,其好处参考多线程异步处理,在此不展开。
以上特性可以用图2.3表示:
![](https://i-blog.csdnimg.cn/blog_migrate/6f3b4fa1256f2e3c2ff2f9ab8b9beaf3.webp?x-image-process=image/format,png)
我们可以看到:1、N次请求其实只建立了1次TCP连接,2、N次请求连续异步发出。
四、HTTP、Socket、TCP的区别
这三个概念经常被谈到,也是比较容易被混掉的概念。在回顾之前我们先看一下这三者在TCP/IP协议族中的位置关系:
![](https://i-blog.csdnimg.cn/blog_migrate/cbe357df65ca05f6d3585c1996e0fa71.webp?x-image-process=image/format,png)
HTTP是应用层的协议,更靠近用户端;TCP是传输层的协议;而socket是从传输层上抽象出来的一个抽象层,本质是接口。所以本质上三种还是很好区分的。尽管如此,有时候你可能会懵逼,HTTP连接、TCP连接、socket连接有什么区别?好吧,如果上面的图解释的还是不够清楚的话,我们继续往下看。
1、TCP连接与HTTP连接的区别
上文提过,HTTP是基于TCP的,客户端往服务端发送一个HTTP请求时第一步就是要建立与服务端的TCP连接,也就是先三次握手,“你好,你好,你好”。从HTTP 1.1开始支持持久连接,也就是一次TCP连接可以发送多次的HTTP请求。
小总结:HTTP基于TCP
2、TCP连接与Socket连接的区别
在图4.1中我们提到,socket层只是在TCP/UDP传输层上做的一个抽象接口层,因此一个socket连接可以基于TCP,也有可能基于UDP。基于TCP协议的socket连接同样需要通过三次握手建立连接,是可靠的;基于UDP协议的socket连接不需要建立连接的过程,不过对方能不能收到都会发送过去,是不可靠的,大多数的即时通讯IM都是后者。
小总结:Socket也可以基于TCP
3、HTTP连接与Socket连接的区别
区分这两个概念是比较有意义的,毕竟TCP看不见摸不着,HTTP与Socket是实实在在能用到的。
- HTTP是短连接,Socket(基于TCP协议的)是长连接。尽管HTTP1.1开始支持持久连接,但仍无法保证始终连接。而Socket连接一旦建立TCP三次握手,除非一方主动断开,否则连接状态一直保持。
- HTTP连接服务端无法主动发消息,Socket连接双方请求的发送先后限制。这点就比较重要了,因为它将决定二者分别适合应用在什么场景下。HTTP采用“请求-响应”机制,在客户端还没发送消息给服务端前,服务端无法推送消息给客户端。必须满足客户端发送消息在前,服务端回复在后。Socket连接双方类似peer2peer的关系,一方随时可以向另一方喊话。
4、问题来了:什么时候该用HTTP,什么时候该用socket
这个问题的提出是很自然而然的。当你接到一个与另一方的网络通讯需求,自然会考虑用HTTP还是用Socket。
- 用HTTP的情况:双方不需要时刻保持连接在线,比如客户端资源的获取、文件上传等
- 用Socket的情况:大部分即时通讯应用(QQ、微信)、聊天室、苹果APNs等
在iOS中,发HTTP请求一般用原生的NSURLConnection
、NSURLSession
或者开源的AFNetWorking(推荐)
、ASIHttpRequest(已停止更新)
。连接Socket连接我用的比较多是robbiehanson大神的CocoaAsyncSocket (XMPPFramework
也是出自他手)。
五、The end
以上就是关于HTTP相关概念的回顾,适合菜鸟也适合有经验同学一起回顾。
欢迎留言,如果写的不对的地方还请不吝指出。