通讯协议 -- HTTP、TCP、UDP

CP  HTTP  UDP:

都是通讯协议，也就是通讯时所遵照的规则，只有双方按照这个规则，对方才能理解并为之服务

TCP   HTTP   UDP三者的关系：

TCP/IP是一个协议组，可分为四个层次：网络接口层、网络层、传输层和应用层

在网络层有IP协议、ICMP协议、ARP协议和BOOTP协议

在传输层有TCP和UDP协议

在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议

所以，HTTP自己就是一个协议，是从web服务器传输超文本到本地浏览器的传输协议。

socket：

这是为了实现以上的通讯过程而创建成来的通讯管道，其真实的表明是客户端和服务器端的一个通讯进程，双方进程经过socket进行通讯，而通讯的规则采用指定的协议。socket只是一种链接模式，不是协议,tcp,udp，简单的说（虽然不许确）是两个最基本的协议,不少其它协议都是基于这两个协议如，http就是基于tcp的，.用socket能够建立tcp链接，也能够建立udp链接，这意味着，用socket能够建立任何协议的链接，由于其它协议都是基于此的。

什么是HTTP协议

HTTP全称是HyperText Transfer Protocal，即：超文本传输协议，Http是应用层协议，当你上网浏览网页的时候，浏览器和Web服务器之间就会经过HTTP进行数据的发送和接收。Http是一个基于请求/响应模式的、无状态的协议。即咱们一般所说的Request/Response。

HTTP的链接：

无状态：指的是服务器没法知道2次请求之间的联系，即便是先后两次是同一个浏览器，也没有任何数据可以判断出是同一个浏览器的请求，后来能够经过cookie、session来判断

有链接：由于它是基于TCP协议，是面向链接的，须要3次握手，4次断开。

短链接：http1.1以前，都是一个请求一个链接，而tcp的链接建立销毁成本高，对服务器又很大的影响，因此，自http1.1开始，支持keep-alive，默认开启，一个链接打开以后，会保持一段时间，浏览器再访问该服务器就使用这个tcp链接，减轻了服务器压力，提升了效率。

URL

URL(Uniform Resource Locator) 地址用于描述一个网络上的资源,  基本格式以下

schema://host[:port#]/path/.../[?query-string][#anchor]

scheme               指定低层使用的协议(例如：http, https, ftp)

host                   HTTP服务器的IP地址或者域名

port#                 HTTP服务器的默认端口是80，这种状况下端口号能够省略。若是使用了别的端口，必须指明，例如 http://www.cnblogs.com:8080/

path                   访问资源的路径

query-string       发送给http服务器的数据

anchor-             锚

 

HTTP的Request/Response：

先看Request消息的结构，Request消息分为3部分：Request line，Request header，Request body，在header和body之间有一个空行

 

第一行Request line中包含：请求方法，资源路径，协议版本号

第二行Request header中：

Accept

做用： 浏览器端能够接受的媒体类型,

例如：  Accept: text/html  表明浏览器能够接受服务器回发的类型为 text/html  也就是咱们常说的html文档,

若是服务器没法返回text/html类型的数据,服务器应该返回一个406错误(non acceptable)

通配符 * 表明任意类型

例如  Accept: */*  表明浏览器能够处理全部类型,(通常浏览器发给服务器都是发这个)

Referer:

做用： 提供了Request的上下文信息的服务器，告诉服务器我是从哪一个连接过来的，好比从我主页上连接到一个朋友那里，他的服务器就可以从HTTP Referer中统计出天天有多少用户点击我主页上的连接访问他的网站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Accept-Language

做用： 浏览器申明本身接收的语言。 

语言跟字符集的区别：中文是语言，中文有多种字符集，好比big5，gb2312，gbk等等；

例如： Accept-Language: en-us

Accept-Encoding：

做用： 浏览器申明本身接收的编码方法，一般指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）

User-Agent

做用：告诉HTTP服务器， 客户端使用的操做系统和浏览器的名称和版本.

Connection

例如：　Connection: keep-alive   当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP链接不会关闭，若是客户端再次访问这个服务器上的网页，会继续使用这一条已经创建的链接

例如：  Connection: close  表明一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP链接会关闭， 当客户端再次发送Request，须要从新创建TCP链接。

Pragma

做用： 防止页面被缓存， 在HTTP/1.1版本中，它和Cache-Control:no-cache做用如出一辙

Pargma只有一个用法， 例如： Pragma: no-cache

Cookie:

做用： 最重要的header, 将cookie的值发送给HTTP 服务器

Accept-Charset

做用：浏览器申明本身接收的字符集，这就是本文前面介绍的各类字符集和字符编码，如gb2312，utf-8

 

Response消息结构和Request消息结构基本同样，也分为三部分：Request line，Request header，Request body，在header和body之间有一个空行

第一行包含：HTTP协议版本号，状态码（200）和信息（ok）

第二行Response Header包含：

Cache-Control

做用: 这个是很是重要的规则。 这个用来指定Response-Request遵循的缓存机制。各个指令含义以下

Cache-Control:Public   能够被任何缓存所缓存（）

Cache-Control:Private     内容只缓存到私有缓存中

Cache-Control:no-cache  全部内容都不会被缓存

Content-Type

做用：WEB服务器告诉浏览器本身响应的对象的类型和字符集,

Expires

做用: 浏览器会在指定过时时间内使用本地缓存

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

Last-Modified:

做用： 用于指示资源的最后修改日期和时间。

Server:

做用：指明HTTP服务器的软件信息

例如:Server: Microsoft-IIS/7.5

X-AspNet-Version:

做用：若是网站是用ASP.NET开发的，这个header用来表示ASP.NET的版本

X-Powered-By:

做用：表示网站是用什么技术开发的

Connection

例如：　Connection: keep-alive   当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP链接不会关闭，若是客户端再次访问这个服务器上的网页，会继续使用这一条已经创建的链接

例如：  Connection: close  表明一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP链接会关闭， 当客户端再次发送Request，须要从新创建TCP链接。

Date

做用:  生成消息的具体时间和日期

例如：　Date: Sat, 11 Feb 2012 11:35:14 GMT

HTTP协议之Get和Post

Http协议定义了不少与服务器交互的方法，最基本的有4种，分别是GET,POST,PUT,DELETE. 一个URL地址用于描述一个网络上的资源，而HTTP中的GET, POST, PUT, DELETE就对应着对这个资源的查，改，增，删4个操做。 咱们最多见的就是GET和POST了。GET通常用于获取/查询资源信息，而POST通常用于更新资源信息.

咱们看看GET和POST的区别

1. GET提交的数据会放在URL以后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456.  POST方法是把提交的数据放在HTTP包的Body中.

2. GET提交的数据大小有限制（由于浏览器对URL的长度有限制），而POST方法提交的数据没有限制.

3. GET方式须要使用Request.QueryString来取得变量的值，而POST方式经过Request.Form来获取变量的值，也就是说Get是经过地址栏来传值，而Post是经过提交表单来传值。

4. GET方式提交数据，会带来安全问题，好比一个登陆页面，经过GET方式提交数据时，用户名和密码将出如今URL上，若是页面能够被缓存或者其余人能够访问这台机器，就能够从历史记录得到该用户的帐号和密码.

 

TCP：

传输控制协议，就是对数据的传输进行必定的控制

链接管理机制：正常状况下，tcp须要通过三次握手创建链接，四次挥手断开链接

三次握手：

刚开始, 客户端和服务器都处于 CLOSE 状态.
此时, 客户端向服务器主动发出链接请求, 服务器被动接受链接请求.

1, TCP服务器进程先建立传输控制块TCB, 时刻准备接受客户端进程的链接请求, 此时服务器就进入了 LISTEN（监听）状态
2, TCP客户端进程也是先建立传输控制块TCB, 而后向服务器发出链接请求报文，此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定, SYN报文段（SYN=1的报文段）不能携带数据，但须要消耗掉一个序号。
3, TCP服务器收到请求报文后, 若是赞成链接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为本身初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据, 可是一样要消耗一个序号。
4, TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1，确认序号是 y+1，本身的序列号是 x+1.
5, 此时，TCP链接创建，客户端进入ESTABLISHED（已创建链接）状态。当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就能够开始通讯了。

第一次:
客户端 - - > 服务器 此时服务器知道了客户端要创建链接了
第二次:
客户端 < - - 服务器 此时客户端知道服务器收到链接请求了
第三次:
客户端 - - > 服务器 此时服务器知道客户端收到了本身的回应

到这里, 就能够认为客户端与服务器已经创建了链接.

为何不用两次握手？

主要是为了防止已经失效的链接请求报文忽然又传送到了服务器，从而产生错误。若是使用的是两次握手创建链接，假设有这样一种场景，客户端发送的第一个请求链接而且没有丢失，只是由于在网络中滞留的时间太长了，因为TCP的客户端迟迟没有收到确认报文，觉得服务器没有收到，此时从新向服务器发送这条报文，此后客户端和服务器通过两次握手完成链接，传输数据，而后关闭链接。此时以前滞留的那一次请求链接，由于网络通畅了, 到达了服务器，这个报文本该是失效的，可是，两次握手的机制将会让客户端和服务器再次创建链接，这将致使没必要要的错误和资源的费。
若是采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文而且回复了确认报文，可是客户端不会再次发出确认。因为服务器收不到确认，就知道客户端并无请求链接。

为何不用四次?

由于三次已经能够知足须要了, 四次就多余了.

 

四次挥手断开

 

 数据传输完毕后，双方均可以释放链接.
此时客户端和服务器都是处于ESTABLISHED状态，而后客户端主动断开链接，服务器被动断开链接.

1, 客户端进程发出链接释放报文，而且中止发送数据。
释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即便不携带数据，也要消耗一个序号。
2, 服务器收到链接释放报文，发出确认报文，ACK=1，确认序号为 u+1，而且带上本身的序列号seq=v，此时服务端就进入了CLOSE-WAIT（关闭等待）状态。
TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，可是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3, 客户端收到服务器的确认请求后，此时客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送链接释放报文（在这以前还须要接受服务器发送的最终数据）
4, 服务器将最后的数据发送完毕后，就向客户端发送链接释放报文，FIN=1，确认序号为v+1，因为在半关闭状态，服务器极可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5, 客户端收到服务器的链接释放报文后，必须发出确认，ACK=1，确认序号为w+1，而本身的序列号是u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP链接尚未释放，必须通过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6, 服务器只要收到了客户端发出的确认，当即进入CLOSED状态。一样，撤销TCB后，就结束了此次的TCP链接。能够看到，服务器结束TCP链接的时间要比客户端早一些。

为何最后客户端还要等待 2*MSL的时间呢?

MSL（Maximum Segment Lifetime），TCP容许不一样的实现能够设置不一样的MSL值。

第一，保证客户端发送的最后一个ACK报文可以到达服务器，由于这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端尚未给我回应，应该是我发送的请求断开报文它没有收到，因而服务器又会从新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，而且会重启2MSL计时器。

第二，防止相似与“三次握手”中提到了的“已经失效的链接请求报文段”出如今本链接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可使本链接持续的时间内所产生的全部报文段都从网络中消失。这样新的链接中不会出现旧链接的请求报文。

为何创建链接是三次握手，关闭链接确是四次挥手呢？

创建链接的时候， 服务器在LISTEN状态下，收到创建链接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭链接时，服务器收到对方的FIN报文时，仅仅表示对方再也不发送数据了可是还能接收数据，而本身也未必所有数据都发送给对方了，因此己方能够当即关闭，也能够发送一些数据给对方后，再发送FIN报文给对方来表示赞成如今关闭链接，所以，己方ACK和FIN通常都会分开发送，从而致使多了一次。

若是已经创建了链接, 可是客户端突发故障了怎么办?

TCP设有一个保活计时器，显然，客户端若是出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会从新复位这个计时器，时间一般是设置为2小时，若两小时尚未收到客户端的任何数据，服务器就会发送一个探测报文段，之后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭链接。

UDP用户数据报协议，是一个无链接的简单的面向数据报的运输层协议，UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，可是并不能保证它们能到达目的地。因为UDP在传输数据报前不用在客户和服务器之间创建一个链接，且没有超时重发等机制，故而传输速度很快。‘

应用场景，视频、音频传输，海量数据采集，通常来讲，丢些包，问题不大，能够从新发送来解决。通常来讲，UDP性能优于TCP，可是可靠性能要求高的场合仍是选择TCP协议。