网络

    /****************************HTTP协议和HTTPS协议********/

- (void)viewDidLoad {

    [super viewDidLoad];

    

    /*

     一、HTTP协议

     

     1、概述

     

     HTTP（超文本传输协议）是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。

     

     HTTP协议的主要特点可概括如下：

     （1）支持客户/服务器模式。

     （2）简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

     （3）灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

     （4）无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

     （5）无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

     

     

     

     2、HTTP之URL

     

     HTTP是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

     

     HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：

     

     

     1

     http://host[":"port][abs_path]

     http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

     

     例如：http://www.imlifengfeng.com/blog

     

     

     

     3、HTTP之请求

     

     http请求由三部分组成，分别是：请求行、消息报头、请求正文

     

     1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：

     

     

     Method Request-URI HTTP-Version CRLF

     其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

     

     根据HTTP标准，HTTP请求可以使用多种请求方法：

     

     HTTP1.0定义了三种请求方法： GET, POST和 HEAD方法。

     

     HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE和 CONNECT方法。

     

     各请求方法描述见下图：

     

     

     在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET和 POST。

     

     GET 和 POST请求的主要区别如下：

     

     GET请求：

     

     （1）主要用于从服务器请求数据，而且请求参数包含在Url之中，如：http://www.imlifengfeng.com/blog/?p=268。由于浏览器对URL的长度有限制，而且每个浏览器的限制可能不同，所以GET请求不能代替POST请求发送大量数据。

     

     （2）由于请求参数可见，敏感数据不应该用Get请求

     

     （3）GET请求可被缓存，可保留在浏览器历史记录中，也可被收藏为书签

     

     POST请求：

     

     （1）主要用于提交数据到服务器，请求参数作为http消息的实际内容发送给web服务器，数据放置在HTML Header内提交，Post没有限制提交的数据。

     

     （2）POST比GET安全，当数据是中文或者不敏感的数据，则用get，因为使用get，参数会显示在地址，对于敏感数据和不是中文字符的数据，则用post。

     

     （3）POST请求不会被缓存，不会保留在浏览器历史记录中，也不能被收藏为书签

     

     

     

     4、HTTP之响应

     

     在接收和解释请求消息后，服务器返回一个HTTP响应消息。

     HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

     

     状态行格式如下：

     

     

     HTTP-Version Status-Code Reason-Phrase CRLF

     其中，HTTP-Version表示服务器HTTP协议的版本；

     

     Status-Code表示服务器发回的响应状态代码；

     

     Reason-Phrase表示状态代码的文本描述。

     

     状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

     

     

     

     1xx：指示信息--表示请求已接收，继续处理

     2xx：成功--表示请求已被成功接收、理解、接受

     3xx：重定向--要完成请求必须进行更进一步的操作

     4xx：客户端错误--请求有语法错误或请求无法实现

     5xx：服务器端错误--服务器未能实现合法的请求

     常见状态代码、状态描述、说明：

     

     200 OK  //客户端请求成功

     400 Bad Request  //客户端请求有语法错误，不能被服务器所理解

     401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报 //头域一起使用

     403 Forbidden  //服务器收到请求，但是拒绝提供服务

     404 Not Found  //请求资源不存在，eg：输入了错误的URL

     500 Internal Server Error //服务器发生不可预期的错误

     503 Server Unavailable  //服务器当前不能处理客户端的请求，一段时间后,可能恢复正常

     

     

     5、HTTP之报头

     

     HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

     

     （1）普通报头

     

     在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。

     

     Cache-Control 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。

     例如：请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;

     响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

     

     

     

     （2）请求报头

     

     请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。

     

     常用的请求报头：

     

     Accept

     Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。

     

     Accept-Charset

     Accept-Charset请求报头域用于指定客户端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。

     

     Accept-Encoding

     Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。

     

     Accept-Language

     Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。

     

     Authorization

     Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

     

     Host（发送请求时，该报头域是必需的）

     Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，eg：

     我们在浏览器中输入：http://www.imlifengfeng.com/blog/?p=268

     浏览器发送的请求消息中，就会包含Host请求报头域，如下：

     Host：www.imlifengfeng.com

     此处使用缺省端口号80，若指定了端口号，则变成：Host：www.imlifengfeng.com:指定端口号

     User-Agent

     我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。

     

     

     

     二、HTTPS协议

     

     HTTPS（Hypertext Transfer Protocol over Secure Socket Layer，基于SSL的HTTP协议）使用了HTTP协议，但HTTPS使用不同于HTTP协议的默认端口及一个加密、身份验证层（HTTP与TCP之间）。这个协议的最初研发由网景公司进行，提供了身份验证与加密通信方法，现在它被广泛用于互联网上安全敏感的通信。HTTPS是一个安全通信通道，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。

     

     HTTPS实际上应用了Netscape的安全全套接字层(SSL)作为HTTP应用层的子层。(HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。)SSL使用40位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X。509数字认证，如果需要的话用户可以确认发送者是谁。

     

     客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤。

     （1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

     （2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

     （3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

     （4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

     （5）Web服务器利用自己的私钥解密出会话密钥。

     （6）Web服务器利用会话密钥加密与客户端之间的通信。

     

     

     

     

     

     三、HTTP和HTTPS的区别

     

     https协议需要到ca申请证书，一般免费证书很少，需要交费。

     http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议 http和https使用的是完全不同的连接方式用的端口也不一样：前者是80，后者是443。

     http的连接很简单，是无状态的 HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议要比http协议安全 HTTPS解决的问题：

     

     （1）信任主机的问题。采用https的server必须从CA申请一个用于证明服务器用途类型的证书。

     

     （2）通讯过程中的数据的泄密和被窜改。一般意义上的https，就是 server有一个证书，少许对客户端有要求的情况下，会要求客户端也必须有一个证书。

     

     

     

     

     

     四、备注：SSL的简介

     SSL是Netscape公司所提出的安全保密协议，在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输，SSL运行在TCP/IP层之上、应用层之下，为应用程序提供加密数据通道，它采用了RC4、MD5以及RSA等加密算法，使用40位的密钥，适用于商业信息的加密。

     

     然而，加密和解密过程需要耗费系统大量的开销，严重降低机器的性能，相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。

     

     

     //http://www.imlifengfeng.com/blog/?p=268

     */

}

    /************************OSI七层模型和TCP/IP四层模型********/

- (void)viewDidLoad {

    [super viewDidLoad];

    

    /*

     1、OSI七层模型

     

     OSI模型，即开放式通信系统互联参考模型(Open System Interconnection,OSI/RM,Open Systems Interconnection Reference Model)，是国际标准化组织(ISO)提出的一个试图使各种计算机在世界范围内互连为网络的标准框架，简称OSI。

     

     

     

     OSI模型从上到下一共分为7层：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。

     

     

     

     OSI 模型各层间关系和通讯时的数据流向如图所示：

     

     

     

     

     下面分别对这7层模型进行介绍：

     

     （1）应用层:

     

     提供OSI用户服务，例如事务处理程序、文件传送协议和网络管理等。

     规定数据的传输协议；

     

     所包含协议：Telnet、FTP、HTTP、SNMP、DNS等。

     

     （2）表示层:

     

     表示层供多种功能用于应用层数据编码和转化,以确保以一个系统应用层发送的信息可以被另一个系统应用层识别。表示层要完成某些特定的功能，主要有不同数据编码格式的转换，提供数据压缩、解压缩服务，对数据进行加密、解密。例如图像格式的显示，就是由位于表示层的协议来支持。

     可以理解为：解决不同系统之间的通信，eg：Linux下的QQ和Windows下的QQ可以通信；

     

     所包含协议：JPEG、MPEG、ASII等

     

     （3）会话层：

     会话层建立、管理和终止表示层与实体之间的通信会话；

     建立一个连接（自动的手机信息、自动的网络寻址）;

     

     所包含协议：NFS、SQL、NETBIOS、RPC等

     

     （4）传输层：

     传输层向高层提供可靠的端到端的网络数据流服务。

     可以理解为：每一个应用程序都会在网卡注册一个端口号，该层就是端口与端口的通信！常用的（TCP／IP）协议；

     

     所包含协议：TCP、UDP、SPX等。

     

     （5）网络层：

     网络层负责在源和终点之间建立连接;

     可以理解为，此处需要确定计算机的位置，怎么确定？IPv4，IPv6！

     

     所包含协议：IP、IPX、OSPF等。

     

     （6）数据链路层:

     数据链路层通过物理网络链路供数据传输。不同的数据链路层定义了不同的网络和协议特征,其中包括物理编址、网络拓扑结构、错误校验、数据帧序列以及流控;

     可以简单的理解为：规定了0和1的分包形式，确定了网络数据包的形式；

     

     所包含协议：SDLC、HDLC、PPP、STP、帧中继等。

     

     （7）物理层：

     物理层负责最后将信息编码成电流脉冲或其它信号用于网上传输；

     eg：RJ45等将数据转化成0和1；

     

     所包含协议：EIA/TIARS-232、EIA/TIARS-449、V.35、RJ-45等。

     

     

     

     2、TCP/IP四层模型

     

     TCP/IP是一组协议的代名词，它还包括许多协议，组成了TCP/IP协议簇。TCP/IP协议被组织成四个概念层，其中有三层对应于ISO参考模型中的相应层：

     

     

     ICP/IP协议族并不包含物理层和数据链路层，因此它不能独立完成整个计算机网络系统的功能，必须与许多其他的协议协同工作。

     

     TCP/IP模型各个层次的功能和协议如下：

     

     

     OSI是一种理论下的模型，而TCP/IP已被广泛使用，成为网络互联事实上的标准。

     

     //http://www.imlifengfeng.com/blog/?p=230

     */

}

    /************************TCP与UDP*******************/

- (void)viewDidLoad {

    [super viewDidLoad];

    

    /*

     1、TCP与UDP概述

     

     TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。TCP中文全名：传输控制协议，UDP中文全名：用户数据报协议。

     

     其中TCP提供IP环境下的数据可靠传输，提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。通俗说，它是事先为所发送的数据开辟出连接好的通道，然后再进行数据发送；

     

     而UDP是一个简单的面向数据报的运输层协议，即面向非连接。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。TCP支持的应用协议主要有：Telnet、FTP、SMTP等；UDP支持的应用层协议主要有：NFS（网络文件系统）、SNMP（简单网络管理协议）、DNS（主域名称系统）、TFTP（通用文件传输协议）等。

     

     在即时通讯中，QQ采用UDP结合TCP、ICQ采用TCP、JABBER基于TCP

     

     

     

     备注：什么是面向连接和面向非连接

     

     “面向连接”就是在正式通信前必须要与对方建立起连接。比如你给别人打电话，必须等线路接通了、对方拿起话筒才能相互通话。

     

     “面向非连接”就是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。与手机短信非常相似：你在发短信的时候，只需要输入对方手机号就OK了。

     

     

     

     2、TCP与UDP的区别

     （1）连接方式

     TCP：需要建立连接,形成传输数据的通道

     UDP：不需要建立连接,将数据源和目的封装成数据包中

     

     （2）数据传输的大小

     TCP：数据大小不收限制，在连接中进行大数据传输

     UDP：每个数据报的大小限制在64K之内

     

     （3）安全性

     TCP：通过三次握手完成连接，因此是可靠协议，安全送达

     UDP：因为无需连接，因此是不可靠协议

     

     （4）效率性

     TCP：必须需要建立连接，所以效率稍微会低些

     UDP：不需要建立连接，速度快

     

     

     

     3、TCP的三次握手与四次挥手

     

     连接三次握手：

     

     TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。这就是面试中经常会被问到的TCP三次握手。只是了解TCP三次握手的概念，对你获得一份工作是没有任何帮助的，你需要去了解TCP三次握手中的一些细节。先来看图说话。

     

     

     

     jellythinktcp4

     

     

     

     多么清晰的一张图，当然了，也不是我做的，是我从网上找来的。

     

     （1）第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

     

     （2）第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

     

     （3）第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

     

     

     

     为了便于理解，我们忽略这些技术概念来理解三次握手：

     

     A:“喂，你听得到吗？”A->SYN_SEND

     

     B:“我听得到呀，你听得到我吗？”应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED

     

     A:“我能听到你，今天balabala……”B->ESTABLISHED

     

     

     

     完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。

     

     

     

     断开连接四次挥手：

     

     当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。

     

     （1）第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；

     

     （2）第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；

     

     （3）第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；

     

     （4）第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

     

     

     

     为了便于理解，我们忽略这些技术概念来理解三次握手：

     

     A:“喂，我不说了。”A->FIN_WAIT1

     

     B:“我知道了。等下，上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2

     

     B:”好了，说完了，我也不说了。”B->LAST_ACK

     

     A:”我知道了。”A->TIME_WAIT | B->CLOSED

     

     A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED

     

     至此，TCP的四次分手就这么愉快的完成了。

     

     

     

     为什么要三次握手？

     

     既然总结了TCP的三次握手，那为什么非要三次呢？怎么觉得两次就可以完成了。那TCP为什么非要进行三次连接呢？在谢希仁的《计算机网络》中是这样说的：

     

     

     1

     为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

     在书中同时举了一个例子，如下：

     

     

     1

     已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

     这就很明白了，防止了服务器端的一直等待而浪费资源。

     

     

     

     为什么要四次挥手？

     

     那四次分手又是为何呢？TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化：

     

     

     

     FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）

     

     

     FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）

     

     

     CLOSE_WAIT：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）

     

     

     LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）

     

     

     TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）

     

     

     CLOSED: 表示连接中断。

     当然，对于面向非连接的UDP则没有上述复杂的过程。

     

     

     

     4、长连接与短连接

     

     所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持。

     

     短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接，一般银行都使用短连接。

     

     

     

     （1）TCP与长连接和短连接

     

     TCP协议中有长连接和短连接之分。短连接在数据包发送完成后就会自己断开。而长连接在发包完毕后，会在一定的时间内保持连接，并且可以继续后续的读写操作，即我们通常所说的Keep alive（存活定时器）功能。它的功效和用户自己实现的心跳机制是一样的。开启Keep alive功能需要消耗额外的宽带和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keep alive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。

     

     但keepalive并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引起一个良好连接（good connection）被释放（dropped），（2）它们消费了不必要的宽带，（3）在以数据包计费的互联网上它们（额外）花费金钱。然而，在许多的实现中提供了存活定时器。

     

     UDP是面向非连接的，所以没有长连接和短连接可言。

     

     

     

     （2）长/短连接的应用场景

     

     长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，再次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket创建也是对资源的浪费。

     

     

     

     而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那后果可想而知。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

     

     

     

     

     

     （3）基于TCP协议的HTTP协议到底是长连接还是短连接（重点）？

     

     在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

     

     但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：

     

     Connection:keep-alive

     

     在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

     

     注意，TCP的keep alive和HTTP的Keep-alive不是同一个东西，TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。

     

     HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

     

     //http://www.imlifengfeng.com/blog/?p=270

     */

}