链路层

链路层提供的服务
封装成帧
链接点接入
可靠交付
差错检测和纠正

网络适配器由控制器和物理线路组成,作用是处理物理层传过来后上升到链路层,对链路层进行的

差错检测和纠正

一般来说因为为了检测会有校验码EDC来保证D数据的正确,所以会有一些多余的开销
,如何让校验码能够在尽可能小的长度内进行有效地差错检测和数据纠正是设计者需要做的。
奇偶检验,通过在后面的检测为加 0 1 来补足偶数奇数,为奇数的为奇校验,偶数为偶校验 引出的问题,单个比特位的差错检测其实很容易,但是多个比特位出差错而且尤其是偶数这样的变化就会导致检测不出(最终偶数奇数未变)

二维奇偶校验 可以检测并纠正,利用行列
XXXX D1 D2 D3 D4 EDC
XXXX 1 1 0 0 0
XXXX 1 0 1 0 0
XEDC 0 1 1 0 0
来通过行列来定位差错比特位
接收方纠错和检测的能力被称为前向纠错 FEC

检验和方法

因特网校验和就是基于检验和方法
即通过二进制加法 然后取反码,最后加在使最后和全为1

循环冗余检测

通过对数据D使用校验码进行XOR余下的余数附加到d数据后,导致可以附加后的数据可以被校验码之后余数为0 所以在传输后检验时,如果没有余数不为0就发生了错误
循环是指xor求余这一循环操作
冗余是指在原数据后附加余数

多路链路访问协议

PPP 点对点链路
多路链路(广播链路)多个发送点,多个接收点
多点链路解决的问题是传输帧时发生碰撞导致无法接受有效信息帧的问题。
基本上划分为三种
信道划分协议 随机接入协议 轮流协议

信道划分协议

TDM FDM 时分复用 频分复用
CDMA 码分多址 利用唯一编码来对发送数据编码而不影响数据发送间的干扰问题
同时也提空了认证问题(即只有编码的人才能收听到相关的信息)

随机接入协议

就是以链路中可传输的最大速度发送帧,当有碰撞时,选择另一随机时间再次发送帧
常用的随机接入协议 ALOHA CSMA
ALOHA 产生碰撞后使用p概率随机发帧,知道发出并且没有产生碰撞位置,时隙高度分散,所以当节点多的有时候会很容易产生碰撞,N个节点成功发送的概率为Np(1-p)**N-1 相对于CSMA没那么常用

载波侦听多路访问 CSMA

两个规则
载波侦听 传输之前先监听一小段时间没有人传输干扰再传输
碰撞检测 传输中检测到发生碰撞 立刻停止传输,然后执行载波侦听过程
合在一起形成完整的具有碰撞检测的载波侦听多路访问 CSMA/CD

检测主要是网络适配器检测出来的,即发送方检测

轮流协议

轮询协议 指定主节点,轮流对其他将要传输的节点发送可传 输的最大数量
用例 802.15 和蓝牙协议
令牌传递协议 持有持有令牌的节点才发送帧,没有主节点,循环传输,1到2,2到3,3到4 N回到1,中间拿到令牌后如果要传输,就传输,不传输就传给下一个节点
用例 光纤分布式数据接口FDDI IEEE802.5令牌环协议

DOCSIS 用于电缆接入因特网的链路层协议

CMTS 电缆调制解调器端接入系统
CMTS 数据经电缆服务接口 规范 DOCSIS使用FDM将下行和上行网络段划分为多个频率信道 下行带宽6MHz 速率最大40Mbps 上行6.4MHz 速率最大30Mbps
因为下行都是CMTS统一发放到相应的电缆调制解调器上,所以一般不会存在碰撞的情况,但是上行信道大家都在向一个CMTS传输自己不同的消息,就会出现
碰撞的情况,一般来说是通过下行MAP帧来指定上行传输的时隙 TDM
最开始确定哪个电缆调制解调器的帧发送,通过特殊的时隙来发送,然后通过下行信道回送帧,来进行交流确定

HTTP详解

原文章   http://network.chinabyte.com/401/13238901.shtml

超文本传输协议(Hypertext Transfer Protocol,简称HTTP)是应用层协议。HTTP 是一种请求/响应式的协议,即一个客户端与服务器建立连接后,向服务器发送一个请求;服务器接到请求后,给予相应的响应信息

  HTTP 请求报文

  HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成,如下图所示:

下面对请求报文格式进行简单的分析:

  请求行:请求行由方法字段、URL 字段 和HTTP 协议版本字段 3 个部分组成,他们之间使用空格隔开。常用的 HTTP 请求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT;

  ● GET:当客户端要从服务器中读取某个资源时,使用GET 方法。GET 方法要求服务器将URL 定位的资源放在响应报文的数据部分,回送给客户端,即向服务器请求某个资源。使用GET 方法时,请求参数和对应的值附加在 URL 后面,利用一个问号(“?”)代表URL 的结尾与请求参数的开始,传递参数长度受限制。例如,/index.jsp?id=100&op=bind。

  ● POST:当客户端给服务器提供信息较多时可以使用POST 方法,POST 方法向服务器提交数据,比如完成表单数据的提交,将数据提交给服务器处理。GET 一般用于获取/查询资源信息,POST 会附带用户数据,一般用于更新资源信息。POST 方法将请求参数封装在HTTP 请求数据中,以名称/值的形式出现,可以传输大量数据;

  请求头部:请求头部由关键字/值对组成,每行一对,关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息,典型的请求头有:

  ● User-Agent:产生请求的浏览器类型;

  ● Accept:客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组,用 “ */* ” 指示可接受全部类型,用“ type/* ”指示可接受 type 类型的所有子类型;

  ● Accept-Language:客户端可接受的自然语言;

  ● Accept-Encoding:客户端可接受的编码压缩格式;

  ● Accept-Charset:可接受的应答的字符集;

  ● Host:请求的主机名,允许多个域名同处一个IP 地址,即虚拟主机;

  ● connection:连接方式(close 或 keepalive);

  ● Cookie:存储于客户端扩展字段,向同一域名的服务端发送属于该域的cookie;

  空行:最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再有请求头;

  请求包体:请求包体不在 GET 方法中使用,而是在POST 方法中使用。POST 方法适用于需要客户填写表单的场合。与请求包体相关的最常使用的是包体类型 Content-Type 和包体长度 Content-Length;

  HTTP 响应报文

  HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成,如下图所示:

 下面对响应报文格式进行简单的分析:
  状态行:状态行由 HTTP 协议版本字段、状态码和状态码的描述文本 3 个部分组成,他们之间使用空格隔开;
  ● 状态码由三位数字组成,第一位数字表示响应的类型,常用的状态码有五大类如下所示:
  1xx:表示服务器已接收了客户端请求,客户端可继续发送请求;
  2xx:表示服务器已成功接收到请求并进行处理;
  3xx:表示服务器要求客户端重定向;
  4xx:表示客户端的请求有非法内容;
  5xx:表示服务器未能正常处理客户端的请求而出现意外错误;
  ● 状态码描述文本有如下取值:
  200 OK:表示客户端请求成功;
  400 Bad Request:表示客户端请求有语法错误,不能被服务器所理解;
  401 Unauthonzed:表示请求未经授权,该状态代码必须与 WWW-Authenticate 报头域一起使用;
  403 Forbidden:表示服务器收到请求,但是拒绝提供服务,通常会在响应正文中给出不提供服务的原因;
  404 Not Found:请求的资源不存在,例如,输入了错误的URL;
  500 Internal Server Error:表示服务器发生不可预期的错误,导致无法完成客户端的请求;
  503 Service Unavailable:表示服务器当前不能够处理客户端的请求,在一段时间之后,服务器可能会恢复正常;
  响应头部:响应头可能包括:
  Location:Location响应报头域用于重定向接受者到一个新的位置。例如:客户端所请求的页面已不存在原先的位置,为了让客户端重定向到这个页面新的位置,服务器端可以发回Location响应报头后使用重定向语句,让客户端去访问新的域名所对应的服务器上的资源;
  Server:Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的,前者发送服务器端软件的信息,后者发送客户端软件(浏览器)和操作系统的信息。
  Vary:指示不可缓存的请求头列表;
  Connection:连接方式;
  对于请求来说:close(告诉 WEB 服务器或者代理服务器,在完成本次请求的响应后,断开连接,不等待本次连接的后续请求了)。keepalive(告诉WEB服务器或者代理服务器,在完成本次请求的响应后,保持连接,等待本次连接的后续请求);
  对于响应来说:close(连接已经关闭); keepalive(连接保持着,在等待本次连接的后续请求); Keep-Alive:如果浏览器请求保持连接,则该头部表明希望WEB 服务器保持连接多长时间(秒);例如:Keep-Alive:300;
  WWW-Authenticate:WWW-Authenticate响应报头域必须被包含在401 (未授权的)响应消息中,这个报头域和前面讲到的Authorization 请求报头域是相关的,当客户端收到 401 响应消息,就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证,就可以发送一个包含了Authorization 报头域的请求;
  空行:最后一个响应头部之后是一个空行,发送回车符和换行符,通知服务器以下不再有响应头部。
  响应包体:服务器返回给客户端的文本信息;
  HTTP 工作原理
  HTTP 协议采用请求/响应模型。客户端向服务器发送一个请求报文,服务器以一个状态作为响应。
  以下是 HTTP 请求/响应的步骤:
  ● 客户端连接到web服务器:HTTP 客户端与web服务器建立一个 TCP 连接;
  ● 客户端向服务器发起 HTTP 请求:通过已建立的TCP 连接,客户端向服务器发送一个请求报文;
  ● 服务器接收 HTTP 请求并返回 HTTP 响应:服务器解析请求,定位请求资源,服务器将资源副本写到 TCP 连接,由客户端读取;
  ● 释放 TCP 连接:若connection 模式为close,则服务器主动关闭TCP 连接,客户端被动关闭连接,释放TCP 连接;若connection 模式为keepalive,则该连接会保持一段时间,在该时间内可以继续接收请求;
  ● 客户端浏览器解析HTML内容:客户端将服务器响应的 html 文本解析并显示;
  例如:在浏览器地址栏键入URL,按下回车之后会经历以下流程:
  1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
  2、解析出 IP 地址后,根据该 IP 地址和默认端口 80,和服务器建立 TCP 连接;
  3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求,该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
  4、服务器对浏览器请求作出响应,并把对应的 html 文本发送给浏览器;
  5、释放 TCP 连接;
  6、浏览器将该 html 文本并显示内容;
  HTTP 无状态性
  HTTP 协议是无状态的(stateless)。也就是说,同一个客户端第二次访问同一个服务器上的页面时,服务器无法知道这个客户端曾经访问过,服务器也无法分辨不同的客户端。HTTP 的无状态特性简化了服务器的设计,使服务器更容易支持大量并发的HTTP 请求。

本质上来说如果想要建立状态链接,可以通过cookie这样的方式来在服务器段保存客户的状态,下次请求的时候,根据cookie验证后再复原保存的状态
  HTTP 持久连接
  HTTP1.0 使用的是非持久连接,主要缺点是客户端必须为每一个待请求的对象建立并维护一个新的连接,即每请求一个文档就要有两倍RTT 的开销。因为同一个页面可能存在多个对象,所以非持久连接可能使一个页面的下载变得十分缓慢,而且这种短连接增加了网络传输的负担。HTTP1.1 使用持久连接keepalive,所谓持久连接,就是服务器在发送响应后仍然在一段时间内保持这条连接,允许在同一个连接中存在多次数据请求和响应,即在持久连接情况下,服务器在发送完响应后并不关闭TCP 连接,而客户端可以通过这个连接继续请求其他对象。
  HTTP/1.1 协议的持久连接有两种方式:
  ● 非流水线方式:客户在收到前一个响应后才能发出下一个请求;
  ● 流水线方式:客户在收到 HTTP 的响应报文之前就能接着发送新的请求报文;
  最后给出一个具体例子:
  Remote Address:116.57.254.104:80 Request URL:http://hr.tencent.com/ Request Method:GET Status Code:200 OK Request Headers GET / HTTP/1.1 Host: hr.tencent.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4 Cookie: pgv_pvi=2098703360; PHPSESSID=bc7onl0dojbsatscsfv79pds77; pgv_info=ssid=s1454606128; pgv_pvid=926725350; ts_uid=4084753309 Response Header HTTP/1.1 200 OK Server: nginx Date: Mon, 26 Jan 2015 01:09:10 GMT Content-Type: text/html;charset=utf-8 Content-Length: 3631 Connection: keep-alive X-Powered-By: PHP/5.3.10 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip
  从请求报文可以知道:
  GET / HTTP/1.1
  请求方法 GET 表示一个读取请求,将从服务器获得网页数据,/表示URL 的路径,URL 总是以/开头,/就表示首页,最后的HTTP/1.1 指示采用的 HTTP 协议版本是 1.1;请求域名如下所示:
  Host: hr.tencent.com
  响应报文如下:
  HTTP/1.1 200 OK

请求报文首部行字段:

详细解释一下各个字段不同的值

Host:对象所在主机

User-Agent:来指明用户代理 扩展文章 https://blog.csdn.net/ahaotata/article/details/84523055

浏览器UA 字串的标准格式为: 浏览器标识 (操作系统标识; 加密等级标识; 浏览器语言) 渲染引擎标识 版本信息

Accept一类的分别是接受的对象类型,接受编码,接受语言

Connect:用于确定是否建立持续性连接

Referer:是指来源,比如点击百度页面中的腾讯,那么显示的来源就是baidu.com之类的

等等还有很多头部字段,这里不再一一讲述

返回报文:

Date:主要的是时间日期

expires:过期时间

set-cookie设置的cookie

Cotent-Length:实体内容的长度

Bdpagetype:应该是百度的页面种类百度自定义的

Bdqid:也是自定义的一个首部行,百度请求id

HTTP状态码详解

常见的HTTP状态码

本内容摘抄自《RESTful WebServices》 中文译本附录B ’42种常见的HTTP响应代码’。
原文作者:Leonard Ricbardson & Sam Ruby
翻译:徐涵、李红军、胡伟

1、三至七种最基本的响应代码

  • 200(“OK”)
    一切正常。实体主体中的文档(若存在的话)是某资源的表示。
  • 400(“Bad Request”)
    客户端方面的问题。实体主题中的文档(若存在的话)是一个错误消息。希望客户端能够理解此错误消息,并改正问题。
  • 500(“Internal Server Error”)
    服务期方面的问题。实体主体中的文档(如果存在的话)是一个错误消息。该错误消息通常无济于事,因为客户端无法修复服务器方面的问题。
  • 301(“Moved Permanently”)
    当客户端触发的动作引起了资源URI的变化时发送此响应代码。另外,当客户端向一个资源的旧URI发送请求时,也发送此响应代码。
  • 404(“Not Found”) 和410(“Gone”)
    当客户端所请求的URI不对应于任何资源时,发送此响应代码。404用于服务器端不知道客户端要请求哪个资源的情况;410用于服务器端知道客户端所请求的资源曾经存在,但现在已经不存在了的情况。
  • 409(“Conflict”)
    当客户端试图执行一个”会导致一个或多个资源处于不一致状态“的操作时,发送此响应代码。

SOAP Web服务只使用响应代码200(“OK”)和500(“Internal Server Error”)。无论是你发给SOAP服务器的数据有问题,还是服务器在处理数据的过程中出现问题,或者SOAP服务器出现内部问题,SOAP服务器均发送500(“Internal Server Error”)。客户端只有查看SOAP文档主体(body)(其中包含错误的描述)才能获知错误原因。客户端无法仅靠读取响应的前三个字节得知请求成功与否。

2、状态码系列。

1XX:通知

1XX系列响应代码仅在与HTTP服务器沟通时使用。

  • 100(“Continue”)
    重要程度:中等,但(写操作时)很少用。

这是对HTTP LBYL(look-before-you-leap)请求的一个可能的响应。该响应代码表明:客户端应重新发送初始请求,并在请求中附上第一次请求时未提供的(可能很大或者包含敏感信息的)表示。客户端这次发送的请求不会被拒绝。对LBYL请求的另一个可能的响应是417(“Expectation Failed”)。

请求报头:要做一个LBYL请求,客户端必须把Expect请求报头设为字符串”100-continue”。除此以外,客户端还需要设置其他一些报头,服务器将根据这些报头决定是响应100还是417。

  • 101(“Switching Protocols”)
    重要程度:非常低。

当客户端通过在请求里使用Upgrade报头,以通知服务器它想改用除HTTP协议之外的其他协议时,客户端将获得此响应代码。101响应代码表示“行,我现在改用另一个协议了”。通常HTTP客户端会在收到服务器发来的101响应后关闭与服务器的TCP连接。101响应代码意味着,该客户端不再是一个HTTP客户端,而将成为另一种客户端。
尽管可以通过Upgrade报头从HTTP切换到HTTPS,或者从HTTP1.1切换到某个未来的版本,但实际使用Upgrade报头的情况比较少。Upgrade报头也可用于HTTP切换到一个完全不同的协议(如IRC)上,但那需要在Web服务器切换为一个IRC服务器的同时,Web客户端切换为一个IRC的客户端,因为服务器将立刻在同一个TCP连接上开始使用新的协议。

请求报头:客户端把Upgrade报头设置为一组希望使用的协议。
响应报头:如果服务器同意切换协议,它就返回一个Upgrade报头,说明它将切换到那个协议,并附上一个空白行。服务器不用关闭TCP链接,而是直接在该TCP连接上开始使用新的协议。

2XX: 成功

2XX系列响应代码表明操作成功了。

  • 200(“OK”)
    重要程度:非常高。

一般来说,这是客户端希望看到的响应代码。它表示服务器成功执行了客户端所请求的动作,并且在2XX系列里没有其他更适合的响应代码了。

实体主体:对于GET请求,服务器应返回客户端所请求资源的一个表示。对于其他请求,服务器应返回当前所选资源的一个表示,或者刚刚执行的动作的一个描述。

-201(“Created”)
重要程度:高。

当服务器依照客户端的请求创建了一个新资源时,发送此响应代码。

响应报头:Location报头应包含指向新创建资源的规范URI。
实体主体:应该给出新创建资源的描述与链接。若已经在Location报头里给出了新资源的URI,那么可以用新资源的一个表示作为实体主体。

-202(“Accepted”)
重要程度:中等。

客户端的请求无法或将不被实时处理。请求稍后会被处理。请求看上去是合法的,但在实际处理它时有出现问题的可能。
若一个请求触发了一个异步操作,或者一个需要现实世界参与的动作,或者一个需要很长时间才能完成且没必要让Web客户端一直等待的动作时,这个相应代码是一个合适的选择。

响应报头:应该把未处理完的请求暴露为一个资源,以便客户端稍后查询其状态。Location报头可以包含指向该资源的URI。
实体主体:若无法让客户端稍后查询请求的状态,那么至少应该提供一个关于何时能处理该请求的估计。

  • 203(“Non-Authoritative Information”)
    重要程度:非常低。

这个响应代码跟200一样,只不过服务器想让客户端知道,有些响应报头并非来自该服务器–他们可能是从客户端先前发送的一个请求里复制的,或者从第三方得到的。

响应报头:客户端应明白某些报头可能是不准确的,某些响应报头可能不是服务器自己生成的,所以服务器也不知道其含义。

  • 204(“No Content”)
    重要程度:高。

若服务器拒绝对PUT、POST或者DELETE请求返回任何状态信息或表示,那么通常采用此响应代码。服务器也可以对GET请求返回此响应代码,这表明“客户端请求的资源存在,但其表示是空的”。注意与304(“Not Modified”)的区别。204常常用在Ajax应用里。服务器通过这个响应代码告诉客户端:客户端的输入已被接受,但客户端不应该改变任何UI元素。

实体主体:不允许。

  • 205(“Reset Content”)
    重要程度:低。

它与204类似,但与204不同的是,它表明客户端应重置数据源的视图或数据结构。假如你在浏览器里提交一个HTML表单,并得到响应代码204,那么表单里的各个字段值不变,可以继续修改它们;但假如得到的响应代码205,那么表单里的各个字段将被重置为它们的初始值。从数据录入方面讲:204适合对单条记录做一系列编辑,而205适于连续输入一组记录。

  • 206(“Partial Content”)
    重要程度:对于支持部分GET(partial GET)的服务而言“非常高”,其他情况下“低”。

它跟200类似,但它用于对部分GET请求(即使用Range请求报头的GET请求)的响应。部分GET请求常用于大型二进制文件的断点续传。

请求报头:客户端为Range请求报头设置一个值。
响应报头:需要提供Date报头。ETag报头与Content-Location报头的值应该跟正常GET请求相同。

若实体主体是单个字节范围(byte range),那么HTTP响应里必须包含一个Content-Range报头,以说明本响应返回的是表示的哪个部分,若实体主体是一个多部分实体(multipart entity)(即该实体主体由多个字节范围构成),那么每一个部分都要有自己的Content-Range报头。
实体主体:不是整个表示,而是一个或者多个字节范围。

3XX 重定向

3XX系列响应代码表明:客户端需要做些额外工作才能得到所需要的资源。它们通常用于GET请求。他们通常告诉客户端需要向另一个URI发送GET请求,才能得到所需的表示。那个URI就包含在Location响应报头里。

  • 300(“Multiple Choices”)
    重要程度:低。

若被请求的资源在服务器端存在多个表示,而服务器不知道客户端想要的是哪一个表示时,发送这个响应代码。或者当客户端没有使用Accept-*报头来指定一个表示,或者客户端所请求的表示不存在时,也发送这个响应代码。在这种情况下,一种选择是,服务器返回一个首选表示,并把响应代码设置为200,不过它也可以返回一个包含该资源各个表示的URI列表,并把响应代码设为300。

响应报头:如果服务器有首选表示,那么它可以在Location响应报头中给出这个首选表示的URI。跟其他3XX响应代码一样,客户端可以自动跟随Location中的URI。
实体主体:一个包含该资源各个表示的URI的列表。可以在表示中提供一些信息,以便用户作出选择。

  • 301(“Moved Permanently”)
    重要程度:中等。

服务器知道客户端试图访问的是哪个资源,但它不喜欢客户端用当前URI来请求该资源。它希望客户端记住另一个URI,并在今后的请求中使用那个新的URI。你可以通过这个响应代码来防止由于URI变更而导致老URI失效。

响应报头:服务器应当把规范URI放在Location响应报头里。
实体主体:服务器可以发送一个包含新URI的信息,不过这不是必需的。

  • 302(“Found”)
    重要程度:应该了解,特别市编写客户端时。但我不推荐使用它。

这个响应代码市造成大多数重定向方面的混乱的最根本原因。它应该是像307那样被处理。实际上,在HTTP 1.0中,响应代码302的名称是”Moved Temporarily”,不幸的是,在实际生活中,绝大多数客户端拿它像303一样处理。它的不同之处在于当服务器为客户端的PUT,POST或者DELETE请求返回302响应代码时,客户端要怎么做。
为了消除这一混淆,在HTTP 1.1中,该响应代码被重命名为”Found”,并新加了一个响应代码307。这个响应代码目前仍在广泛使用,但它的含义市混淆的,所以我建议你的服务发送307或者303,而不要发送302.除非你知道正在与一个不能理解303或307的HTTP 1.0客户端交互。

响应报头:把客户端应重新请求的那个URI放在Location报头里。
实体主体:一个包含指向新URI的链接的超文本文档(就像301一样)。

  • 303(“See Other”)
    重要程度:高。

请求已经被处理,但服务器不是直接返回一个响应文档,而是返回一个响应文档的URI。该响应文档可能是一个静态的状态信息,也可能是一个更有趣的资源。对于后一种情况,303是一种令服务器可以“发送一个资源的表示,而不强迫客户端下载其所有数据”的方式。客户端可以向Location报头里的URI发送GET请求,但它不是必须这么做。
303响应代码是一种规范化资源URI的好办法。一个资源可以有多个URIs,但每个资源的规范URI只有一个,该资源的所有其他URIs都通过303指向该资源的规范URI,例如:303可以把一个对http://www.example.com/software/current.tar.gz的请求重定向到http://www.example.com/software/1.0.2.tar.gz。

响应报头:Location报头里包含资源的URI。
实体主体:一个包含指向新URI的链接的超文本文档。

  • 304(“Not Modified”)
    重要程度:高。

这个响应代码跟204(“No Content”)类似:响应实体主体都必须为空。但204用于没有主体数据的情况,而304用于有主体数据,但客户端已拥有该数据,没必要重复发送的情况。这个响应代码可用于条件HTTP请求(conditional HTTP request).如果客户端在发送GET请求时附上了一个值为Sunday的If-Modified-Since报头,而客户端所请求的表示在服务器端自星期日(Sunday)以来一直没有改变过,那么服务器可以返回一个304响应。服务器也可以返回一个200响应,但由于客户端已拥有该表示,因此重复发送该表示只会白白浪费宽带。

响应报头:需要提供Date报头。Etag与Content-Location报头的值,应该跟返回200响应时的一样。若Expires, Cache-Control及Vary报头的值自上次发送以来已经改变,那么就要提供这些报头。
实体主体:不允许。

  • 305(“Use Proxy”)
    重要程度:低。

这个响应代码用于告诉客户端它需要再发一次请求,但这次要通过一个HTTP代理发送,而不是直接发送给服务器。这个响应代码使用的不多,因为服务器很少在意客户端是否使用某一特定代理。这个代码主要用于基于代理的镜像站点。现在,镜像站点(如http://www.example.com.mysite.com/)包含跟原始站点(如 http://www.example.com/)一样的内容,但具有不同的URI,原始站点可以通过307把客户端重新定向到镜像站点上。假如有基于代理的镜像站点,那么你可以通过把 http://proxy.mysite.com/设为代理,使用跟原始URI(http://www.example.com/)一样的URI来访问镜像站点。这里,原始站点example.com可以通过305把客户端路由到一个地理上接近客户端的镜像代理。web浏览器一般不能正确处理这个响应代码,这是导致305响应代码用的不多的另一个原因

响应报头:Location报头里包含代理的URI。

  • 306 未使用
    重要程度:无

306 响应代码没有在HTTP标准中定义过。

  • 307(“Temporary Redirect”)
    重要程度:高。

请求还没有被处理,因为所请求的资源不在本地:它在另一个URI处。客户端应该向那个URI重新发送请求。就GET请求来说,它只是请求得到一个表示,该响应代码跟303没有区别。当服务器希望把客户端重新定向到一个镜像站点时,可以用307来响应GET请求。但对于POST,PUT及DELETE请求,它们希望服务器执行一些操作,307和303有显著区别。对POST,PUT或者DELETE请求响应303表明:操作已经成功执行,但响应实体将不随本响应一起返回,若客户端想要获取响应实体主体,它需要向另一个URI发送GET请求。而307表明:服务器尚未执行操作,客户端需要向Location报头里的那个URI重新提交整个请求。

响应报头: 把客户端应重新请求的那个URI放在Location报头里。
实体主体:一个包含指向新URI的链接的超文本文档。

4XX:客户端错误

这些响应代码表明客户端出现错误。不是认证信息有问题,就是表示格式或HTTP库本身有问题。客户端需要自行改正。

  • 400(“Bad Request”)
    重要程度:高。

这是一个通用的客户端错误状态,当其他4XX响应代码不适用时,就采用400。此响应代码通常用于“服务器收到客户端通过PUT或者POST请求提交的表示,表示的格式正确,但服务器不懂它什么意思”的情况。

实体主体:可以包含一个错误的描述文档。

  • 401(“Unauthorized”)
    重要程度:高。

客户端试图对一个受保护的资源进行操作,却又没有提供正确的认证证书。客户端提供了错误的证书,或者根本没有提供证书。这里的证书(credential)可以是一个用户名/密码,也可以市一个API key,或者一个认证令牌。客户端常常通过向一个URI发送请求,并查看收到401响应,以获知应该发送哪种证书,以及证书的格式。如果服务器不想让未授权的用户获知某个资源的存在,那么它可以谎报一个404而不是401。这样做的缺点是:客户端需要事先知道服务器接受哪种认证–这将导致HTTP摘要认证无法工作。

响应报头:WWW-Authenticate报头描述服务器将接受哪种认证。
实体主体:一个错误的描述文档。假如最终用户可通过“在网站上注册”的方式得到证书,那么应提供一个指向该注册页面的链接。

  • 402(“Payment Required”)
    重要程度:无。

除了它的名字外,HTTP标准没有对该响应的其他方面作任何定义。因为目前还没有用于HTTP的微支付系统,所以它被留作将来使用。尽管如此,若存在一个用于HTTP的微支付系统,那么这些系统将首先出现在web服务领域。如果想按请求向用户收费,而且你与用户之间的关系允许这么做的话,那么或许用得上这个响应代码。
注:该书印于2008年

  • 403(“Forbidden”)
    重要程度:中等。

客户端请求的结构正确,但是服务器不想处理它。这跟证书不正确的情况不同–若证书不正确,应该发送响应代码401。该响应代码常用于一个资源只允许在特定时间段内访问,
或者允许特定IP地址的用户访问的情况。403暗示了所请求的资源确实存在。跟401一样,若服务器不想透露此信息,它可以谎报一个404。既然客户端请求的结构正确,那为什么还要把本响应代码放在4XX系列(客户端错误),而不是5XX系列(服务端错误)呢?因为服务器不是根据请求的结构,而是根据请求的其他方面(比如说发出请求的时间)作出的决定的。

实体主体:一个描述拒绝原因的文档(可选)。

  • 404(“Not Found”)
    重要程度:高。

这也许是最广为人知的HTTP响应代码了。404表明服务器无法把客户端请求的URI转换为一个资源。相比之下,410更有用一些。web服务可以通过404响应告诉客户端所请求的URI是空的,然后客户端就可以通过向该URI发送PUT请求来创建一个新资源了。但是404也有可能是用来掩饰403或者401.

  • 405(“Method Not Allowd”)
    重要程度:中等。

客户端试图使用一个本资源不支持的HTTP方法。例如:一个资源只支持GET方法,但是客户端使用PUT方法访问。

响应报头:Allow报头列出本资源支持哪些HTTP方法,例如:Allow:GET,POST

  • 406(“Not Acceptable”)
    重要程度:中等。

当客户端对表示有太多要求,以至于服务器无法提供满足要求的表示,服务器可以发送这个响应代码。例如:客户端通过Accept头指定媒体类型为application/json+hic,但是服务器只支持application/json。服务器的另一个选择是:忽略客户端挑剔的要求,返回首选表示,并把响应代码设为200。

实体主体:一个可选表示的链接列表。

  • 407(“Proxy Authentication Required”)
    重要程度:低。

只有HTTP代理会发送这个响应代码。它跟401类似,唯一区别在于:这里不是无权访问web服务,而是无权访问代理。跟401一样,可能是因为客户端没有提供证书,也可能是客户端提供的证书不正确或不充分。

请求报头:客户端通过使用Proxy-Authorization报头(而不是Authorization)把证书提供给代理。格式跟Authrization一样。
响应报头:代理通过Proxy-Authenticate报头(而不是WWW-Authenticate)告诉客户端它接受哪种认证。格式跟WWW-Authenticate一样。

  • 408(“Reqeust Timeout”)
    重要程度:低。

假如HTTP客户端与服务器建立链接后,却不发送任何请求(或从不发送表明请求结束的空白行),那么服务器最终应该发送一个408响应代码,并关闭此连接。

  • 409(“Conflict”)
    重要程度:高。

此响应代码表明:你请求的操作会导致服务器的资源处于一种不可能或不一致的状态。例如你试图修改某个用户的用户名,而修改后的用户名与其他存在的用户名冲突了。

响应报头:若冲突是因为某个其他资源的存在而引起的,那么应该在Location报头里给出那个资源的URI。
实体主体:一个描述冲突的文档,以便客户端可以解决冲突。

  • 410(“Gone”)
    重要程度:中等。

这个响应代码跟404类似,但它提供的有用信息更多一些。这个响应代码用于服务器知道被请求的URI过去曾指向一个资源,但该资源现在不存在了的情况。服务器不知道
该资源的新URI,服务器要是知道该URI的话,它就发送响应代码301.410和310一样,都有暗示客户端不应该再请求该URI的意思,不同之处在于:410只是指出该资源不存在,但没有给出该资源的新URI。RFC2616建议“为短期的推广服务,以及属于个人但不继续在服务端运行的资源”采用410.

  • 411(“Length Required”)
    重要程度:低到中等。

若HTTP请求包含表示,它应该把Content-Length请求报头的值设为该表示的长度(以字节为单位)。对客户端而言,有时这不太方便(例如,当表示是来自其他来源的字节流时)。
所以HTTP并不要求客户端在每个请求中都提供Content-Length报头。但HTTP服务器可以要求客户端必须设置该报头。服务器可以中断任何没有提供Content-Length报头的请求,并要求客户端重新提交包含Content-Length报头的请求。这个响应代码就是用于中断未提供Content-Lenght报头的请求的。假如客户端提供错误的长度,或发送超过长度的表示,服务器可以中断请求并关闭链接,并返回响应代码413。

  • 412(“Precondition Failed”)
    重要程度:中等。

客户端在请求报头里指定一些前提条件,并要求服务器只有在满足一定条件的情况下才能处理本请求。若服务器不满足这些条件,就返回此响应代码。If-Unmodified-Since是一个常见的前提条件。客户端可以通过PUT请求来修改一个资源,但它要求,仅在自客户端最后一次获取该资源后该资源未被别人修改过才能执行修改操作。若没有这一前提条件,客户端可能会无意识地覆盖别人做的修改,或者导致409的产生。

请求报头:若客户但设置了If-Match,If-None-Match或If-Unmodified-Since报头,那就有可能得到这个响应代码。If-None-Match稍微特别一些。若客户端在发送GET或HEAD请求时指定了If-None-Match,并且服务器不满足该前提条件的话,那么响应代码不是412而是304,这是实现条件HTTP GET的基础。若客户端在发送PUT,POST或DELETE请求时指定了If-None-Match,并且服务器不满足该前提条件的话,那么响应代码是412.另外,若客户端指定了If-Match或If-Unmodified-Since(无论采用什么HTTP方法),而服务器不满足该前提条件的话,响应代码也是412。

  • 413(“Request Entity Too Large”)
    重要程度:低到中等。

这个响应代码跟411类似,服务器可以用它来中断客户端的请求并关闭连接,而不需要等待请求完成。411用于客户端未指定长度的情况,而413用于客户端发送的表示太大,以至于服务器无法处理。客户端可以先做一个LBYL(look-before-you-leap)请求,以免请求被413中断。若LBYL请求获得响应代码为100,客户端再提交完整的表示。

响应报头:如果因为服务器方面临时遇到问题(比如资源不足),而不是因为客户端方面的问题而导致中断请求的话,服务器可以把Retry-After报头的值设为一个日期或一个间隔时间,以秒为单位,以便客户端可以过段时间重试。

  • 414(“Request-URI Too Long”)
    重要程度:低。

HTTP标准并没有对URI长度作出官方限制,但大部分现有的web服务器都对URI长度有一个上限,而web服务可能也一样。导致URI超长的最常见的原因是:表示数据明明是该放在实体主体里的,但客户端却把它放在了URI里。深度嵌套的数据结构也有可能引起URI过长。

  • 415(“Unsupported Media Type”)
    重要程度:中等。

当客户端在发送表示时采用了一种服务器无法理解的媒体类型,服务器发送此响应代码。比如说,服务器期望的是XML格式,而客户端发送的确实JSON格式。
如果客户端采用的媒体类型正确,但格式有问题,这时最好返回更通用的400。

  • 416(“Requestd Range Not Satisfiable”)
    重要程度:低。

当客户端所请求的字节范围超出表示的实际大小时,服务器发送此响应代码。例如:你请求一个表示的1-100字节,但该表示总共只用99字节大小。

请求报头:仅当原始请求里包含Range报头时,才有可能收到此响应代码。若原始请求提供的是If-Range报头,则不会收到此响应代码。
响应报头:服务器应当通过Content-Range报头告诉客户端表示的实际大小。

  • 417(“Expectation Failed”)
    重要程度:中等。

此响应代码跟100正好相反。当你用LBYL请求来考察服务器是否会接受你的表示时,如果服务器确认会接受你的表示,那么你将获得响应代码100,否则你将获得417。

5XX 服务端错误

这些响应代码表明服务器端出现错误。一般来说,这些代码意味着服务器处于不能执行客户端请求的状态,此时客户端应稍后重试。有时,服务器能够估计客户端应在多久之后重试。并把该信息放在Retry-After响应报头里。

5XX系列响应代码在数量上不如4XX系列多,这不是因为服务器错误的几率小,而是因为没有必要如此详细–对于服务器方面的问题,客户端是无能为力的。

  • 500(“Internal Server Error”)
    重要程度:高。

这是一个通用的服务器错误响应。对于大多数web框架,如果在执行请求处理代码时遇到了异常,它们就发送此响应代码。

  • 501(“Not Implemented”)
    重要程度:低。

客户端试图使用一个服务器不支持的HTTP特性。
最常见的例子是:客户端试图做一个采用了拓展HTTP方法的请求,而普通web服务器不支持此请求。它跟响应代码405比较相似,405表明客户端所用的方法是一个可识别的方法,但该资源不支持,而501表明服务器根本不能识别该方法。

  • 502(“Bad Gateway”)
    重要程度:低。

只有HTTP代理会发送这个响应代码。它表明代理方面出现问题,或者代理与上行服务器之间出现问题,而不是上行服务器本身有问题。若代理根本无法访问上行服务器,响应代码将是504。

  • 503(“Service Unavailable”)
    重要程度:中等到高。

此响应代码表明HTTP服务器正常,只是下层web服务服务不能正常工作。最可能的原因是资源不足:服务器突然收到太多请求,以至于无法全部处理。由于此问题多半由客户端反复发送请求造成,因此HTTP服务器可以选择拒绝接受客户端请求而不是接受它,并发送503响应代码。

响应报头:服务器可以通过Retry-After报头告知客户端何时可以重试。

  • 504(“Gateway Timeout”)
    重要程度:低。

跟502类似,只有HTTP代理会发送此响应代码。此响应代码表明代理无法连接上行服务器。

  • 505(“HTTP Version Not Supported”)
    重要程度: 非常低。

计算机网络基础知识

时延种类:处理时延,排队时延,传输时延(从终端推到链路中的消耗时间),传播时延(链路中包传播消耗的时间)
总时延=处理+排队+传输+传播

五层因特网协议栈

应用层 运输层 网络层 链路层 物理层

七层ISO OSI参考模型

应用层 表示层 会话层 运输层 网络层 链路层 物理层

常用端口

HTTP:80:www服务。

DHCP:服务器端的端口号是67

DHCP:客户机端的端口号是68

POP3:POP3仅仅是接收协议,POP3客户端使用SMTP向服务器发送邮件。POP3所用的端口号是110。

SMTP:端口号是25。SMTP真正关心的不是邮件如何被传送,而只关心邮件是否能顺利到达目的地。SMTP具有健壮的邮件处

理特性,这种特性允许邮件依据一定标准自动路由,SMTP具有当邮件地址不存在时立即通知用户的能力,并且具有在一定

时间内将不可传输的邮件返回发送方的特点。

Telnet:端口号是23。Telnet是一种最老的Internet应用,起源于ARPNET。它的名字是“电信网络协议

(Telecommunication Network Protocol)”的缩写。

FTP:FTP使用的端口有20和21。20端口用于数据传输,21端口用于控制信令的传输,控制信息和数据能够同时传输,这是

FTP的特殊这处。FTP采用的是TCP连接。

TFTP:端口号69,使用的是UDP的连接。

DNS:53,名称服务

NetBIOS:137,138,139,其中137、138是UDP端口,当通过网上邻居传输文件时用这个端口。而139端口:通过这个端口进入

的连接试图获得NetBIOS/SMB服务。这个协议被用于windows文件和打印机共享和 SAMBA。还有WINS Regisrtation也用它。

NNTP 网络新闻传输协议:119

SNMP(简单网络管理协议):161端口

RPC(远程过程调用)服务:135端口

QQ:使用8000(服务端)和4000端口(客户端)

21 端口:21 端口主要用于FTP(File Transfer Protocol,文件传输协议)服务。

23 端口:23 端口主要用于Telnet(远程登录)服务,是Internet上普遍采用的登录和仿真程序。

25 端口:25 端口为SMTP(Simple Mail Transfer Protocol,简单邮件传输协议)服务器所开放,主要用于发送邮件,如

今绝大多数邮件服务器都使用该协议。

53 端口:53 端口为DNS(Domain Name Server,域名服务器)服务器所开放,主要用于域名解析,DNS 服务在NT 系统中

使用的最为广泛。

67、68 端口:67、68 端口分别是为Bootp 服务的Bootstrap Protocol Server(引导程序协议服务端)和Bootstrap

Protocol Client(引导程序协议客户端)开放的端口。

69 端口:TFTP 是Cisco 公司开发的一个简单文件传输协议,类似于FTP。

79 端口:79 端口是为Finger 服务开放的,主要用于查询远程主机在线用户、操作系统类型以及是否缓冲区溢出等用户的

详细信息。

80 端口:80 端口是为HTTP(HyperText Transport Protocol,超文本传输协议)开放的,这是上网冲浪使用最多的协议

,主要用于在WWW(World Wide Web,万维网)服务上传输信息的协议。

99 端口:99 端口是用于一个名为“Metagram Relay”(亚对策延时)的服务该服务比较少见,一般是用不到的。

109、110 端口:109 端口是为POP2(Post Office Protocol Version2,邮局协议2)服务开放的,110 端口是为POP3(邮

件协议3)服务开放的,POP2、POP3 都是主要用于接收邮件的。

111 端口:111 端口是SUN 公司的RPC(Remote Procedure Call,远程过程调用)服务所开放的端口,主要用于分布式系

统中不同计算机的内部进程通信,RPC 在多种网络服务中都是很重要的组件。

113 端口:113 端口主要用于Windows 的“Authentication Service”(验证服务)。

119 端口:119 端口是为“Network News Transfer Protocol”(网络新闻组传输协议,简称NNTP)开放的。

135 端口:135 端口主要用于使用RPC(Remote Procedure Call,远程过程调用)协议并提供DCOM(分布式组件对象模型

)服务。

137 端口:137 端口主要用于“NetBIOS Name Service”(NetBIOS名称服务)。

139 端口:139 端口是为“NetBIOS Session Service”提供的,主要用于提供Windows 文件和打印机共享以及Unix 中的

Samba 服务。

143 端口:143 端口主要是用于“Internet Message Access Protocol”v2(Internet 消息访问协议,简称IMAP)。

161 端口:161 端口是用于“Simple Network Management Protocol”(简单网络管理协议,简称SNMP)。

443 端口:443 端口即网页浏览端口,主要是用于HTTPS 服务,是提供加密和通过安全端口传输的另一种HTTP。

554 端口:554 端口默认情况下用于“Real Time Streaming Protocol”(实时流协议,简称RTSP)。

1024 端口:1024 端口一般不固定分配给某个服务,在英文中的解释是“Reserved”(保留)。

1080 端口:1080 端口是Socks 代理服务使用的端口,大家平时上网使用的WWW 服务使用的是HTTP 协议的代理服务。

1755 端口:1755 端口默认情况下用于“Microsoft Media Server”(微软媒体服务器,简称MMS)。

3389端口:远程桌面