C# HTTP1.0 1.1 2.0与HTTPS 、TCP/IP协议的UDP与TCP、 Socket介绍与WebSocket

时间：2023-03-09 16:57:51
C# HTTP1.0 1.1 2.0与HTTPS 、TCP/IP协议的UDP与TCP、 Socket介绍与WebSocket

一.HTTP1.0 1.1 2.0和HTTPS

1.HTTP协议是什么？

HTTP协议是超文本传输协议的缩写，英文是Hyper Text Transfer Protocol。它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议。

超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。

2.HTTP原理

HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML 文件,、图片文件, 查询结果等。

HTTP协议一般用于B/S架构（）。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

  1. DNS域名解析为服务器IP
  2. 发起TCP请求，3次握手建立连接
  3. HTTP请求
  4. HTTP响应

请求报文：

  1. 请求行：包括请求方法、URL、协议/版本

  2. 请求头(Request Header)

  3. 请求正文

响应报文

  1. 状态行
  2. 响应头
  3. 响应正文

3.请求方式

  • GET:请求指定的页面信息，并返回实体主体。
  • POST:向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
  • HEAD:类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
  • PUT:从客户端向服务器传送的数据取代指定的文档的内容。
  • DELETE:请求服务器删除指定的页面。

post和get的区别：

  • 都包含请求头请求行，post多了请求body。
  • get多用来查询，请求参数放在url中，不会对服务器上的内容产生作用。post用来提交，如把账号密码放入body中。
  • GET是直接添加到URL后面的，直接就可以在URL中看到内容，而POST是放在报文内部的，用户无法直接看到。
  • GET提交的数据长度是有限制的，因为URL长度有限制，具体的长度限制视浏览器而定。而POST没有。

4.响应状态码

访问一个网页时，浏览器会向web服务器发出请求。此网页所在的服务器会返回一个包含HTTP状态码的信息头用以响应浏览器的请求。

状态码分类：

  • 1XX- 信息型，服务器收到请求，需要请求者继续操作。
  • 2XX- 成功型，请求成功收到，理解并处理。
  • 3XX - 重定向，需要进一步的操作以完成请求。
  • 4XX - 客户端错误，请求包含语法错误或无法完成请求。
  • 5XX - 服务器错误，服务器在处理请求的过程中发生了错误。

常见状态码：

  • 200 OK - 客户端请求成功
  • 301 - 资源（网页等）被永久转移到其它URL
  • 302 - 临时跳转
  • 400 Bad Request - 客户端请求有语法错误，不能被服务器所理解
  • 401 Unauthorized - 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
  • 404 - 请求资源不存在，可能是输入了错误的URL
  • 500 - 服务器内部发生了不可预期的错误
  • 503 Server Unavailable - 服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

5.为什么要用https？

实际使用中，绝大说的网站现在都采用的是https协议，这也是未来互联网发展的趋势。下面是通过wireshark抓取的一个博客网站的登录请求过程。

可以看到访问的账号密码都是明文传输， 这样客户端发出的请求很容易被不法分子截取利用，因此，HTTP协议不适合传输一些敏感信息，比如：各种账号、密码等信息，使用http协议传输隐私信息非常不安全。

一般http中存在如下问题：

  • 请求信息明文传输，容易被窃听截取。
  • 数据的完整性未校验，容易被篡改
  • 没有验证对方身份，存在冒充危险

为了解决上述HTTP存在的问题，就用到了HTTPS。

HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：一般理解为HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。

那么SSL又是什么？

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

6.HTTPS传输流程

  1. 首先客户端通过URL访问服务器建立SSL连接。
  2. 服务端收到客户端请求后，会将网站支持的证书信息（证书中包含公钥）传送一份给客户端。
  3. 客户端的服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
  4. 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
  5. 服务器利用自己的私钥解密出会话密钥。
  6. 服务器利用会话密钥加密与客户端之间的通信。

7.HTTPS与HTTP比较

  • HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。

  • HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。

  • HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

  • HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTPS缺点

  • HTTPS协议多次握手，导致页面的加载时间延长近50%；
  • HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗；
  • 申请SSL证书需要钱，功能越强大的证书费用越高。
  • SSL涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大。

8.HTTP1.0和HTTP1.1的一些区别

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

  1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

  2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者*的选择以便于充分利用带宽和连接。

  3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

  4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

  5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

  6. 2012年google如一声惊雷提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

    1. 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。

    2. 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。

    3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。

    4. 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。

    5. 服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了

9.HTTP2.0性能惊人

HTTP/2: the Future of the Internet https://link.zhihu.com/?target=https://http2.akamai.com/demo 是 Akamai 公司建立的一个官方的演示，用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379 张图片，从Load time 的对比可以看出 HTTP/2 在速度上的优势。

HTTP2.0和HTTP1.X相比的新特性

  • 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

  • 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

  • header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

  • 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

HTTP2.0的升级改造

  • 前文说了HTTP2.0其实可以支持非HTTPS的，但是现在主流的浏览器像chrome，firefox表示还是只支持基于 TLS 部署的HTTP2.0协议，所以要想升级成HTTP2.0还是先升级HTTPS为好。

  • 当你的网站已经升级HTTPS之后，那么升级HTTP2.0就简单很多，如果你使用NGINX，只要在配置文件中启动相应的协议就可以了，可以参考NGINX白皮书，NGINX配置HTTP2.0官方指南 https://www.nginx.com/blog/nginx-1-9-5/。

  • 使用了HTTP2.0那么，原本的HTTP1.x怎么办，这个问题其实不用担心，HTTP2.0完全兼容HTTP1.x的语义，对于不支持HTTP2.0的浏览器，NGINX会自动向下兼容的。

二.TCP/IP的UDP和TCP

TCP/IP传输层的两个主要协议都是因特网的重要标准，传输控制协议TCP、用户数据报协议UDP
TCP/IP是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是TCP 和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇，
只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议

TCP与UDP区别总结：　　

　　1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
　　2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保 证可靠交付
　　3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
　　UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
　　4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
　　5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
　　6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

TCP 与 UDP 的应用场景

　　从特点上我们已经知道，TCP 是可靠的但传输速度慢 ，UDP 是不可靠的但传输速度快。因此在选用具体协议通信时，应该根据通信数据的要求而决定。
　　若通信数据完整性需让位与通信实时性，则应该选用 TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。

TCP&UDP的比较

TCP（Transmission Control Protocol）可靠的、面向连接的协议（eg:打电话）、传输效率低全双工通信（发送缓存&接收缓存）、面向字节流。使用TCP的应用：Web浏览器；电子邮件、文件传输程序。

　　TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP传输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，传输连接就由三个阶段，即：连接建立、数据传送和连接释放。

这里的SYN=SYNchronization，SYN=1,ACK=0,表示连接请求报文段；同意建立连接则SYN=1，ACK=1，连接后所有的ACK=1。

　　三次握手(three-way handshake)方案解决了由于网络层会丢失、存储和重复分组带来的问题。试想不进行三次握手可能出现的问题？

如果仅仅是2次握手的话，可能出现的问题如下：

　Host A发送的数据包由于网络的原因，出现了滞留，即延时到达了HostB。此时，B以为HostA发来了请求，于是就向HostA发送确认报文，以建立连接。而HostA收到报文后，由于其没有向HostB发起建立连接的请　求，因此不会理睬HostB的确认，也不会向HostB发送数据。而此时的B认为已经建立起连接了，就等待HostA发送的数据，导致HostB的资源白白浪费！

UDP（User Datagram Protocol）不可靠的、无连接的服务，传输效率高（发送前时延小），一对一、一对多、多对一、多对多、面向报文，尽最大努力服务，无拥塞控制。使用UDP的应用：域名系统 (DNS)；视频　流；IP语音(VoIP)。

视屏、会话和语音电话，丢失一部分数据影响不大，不在乎数据的正确性。简洁、快速、高效，但不能提供必要的差错控制报文，同时在拥塞控制严重时缺乏必要的控制和调节机制。

  • 与TCP相比，UDP不提供流量控制、数据应答和状态维护，最大的优势就是快，无连接，不保证数据的正确性，也不保证数据顺序，是一种无序的存在。

问题1：什么是面向连接、面向无连接？

面向连接举例：两个人之间通过电话进行通信。

面向无连接举例：邮政服务，用户把信函放在邮件中期待邮政处理流程来传递邮政包裹。显然，不可达代表不可靠。

从程序实现的角度解析面向连接、面向无连接如下：

TCP面向连接，UDP面向无连接（在默认的阻塞模式下）：

在TCP协议中，当客户端退出程序或断开连接时，TCP协议的recv函数会立即返回不再阻塞，因为服务端自己知道客户端已经退出或断开连接，证明它是面向连接的；

而在UDP协议中，recvfrom这个接收函数将会始终保持阻塞，因为服务端自己不知道客户端已经退出或断开连接，证明它是面向无连接的）。

从TCP通信需要服务器端侦听listen、接收客户端连接请求accept，等待客户端connect建立连接后才能进行数据包的收发（recv/send）工作。

而UDP则服务器和客户端的概念不明显，服务器端即接收端需要绑定端口，等待客户端的数据的到来。后续便可以进行数据的收发（recvfrom/sendto）工作。

问题2：UDP 如何发送大量的数据？如何处理分包？

用 updclient 一次不能发送太大的数据量，不然就会报错：一个在数据报套接字上发送的消息大于内部消息缓冲器或其他一些网络限制，或该用户用于接收数据报的缓冲器比数据报小。但不知道一次到底能发多少字节？如果把一个大的字节数组拆分成若干个字节数组发送，那么接收时如何判断和处理呢？

答：方法很简单：

　　　　1、在客户端将你要发送的内容（文件什么的都可以）分块，每块内容进行编号，然后发送；

　　　　2、服务端在接收到你的分块数据以后，根据你的客户端数据内容的编号重新组装；

　　　　3、一般我们在发送数据的时候，尽量采用比较小的数据块的方式（我的都没有超过1024的），数据块太大的话容易出现发送和接收的数据时间长，匹配出问题。

问题3：TCP的四次握手（TCP的3次握手建立连接，4次握手释放连接）

建立起一个TCP连接需要经过“三次握手”：

1.第一次握手：客户端首先向服务端发送请求，tcp报文头中发送标识SYN=1(SYN表示客户端请求跟服务端建立连接),序号Seq=x。

2.第二次握手：服务端在接收到客户端发送的请求之后，需要告诉客户端已收到请求，tcp报文头中发送标识SYN=1,ACK=1(SYN表示服务端请求跟客户端建立连接，ACK表示对客户端的连接请求进行应答),序号Seq=y,确认号=x+1（表示对客户端发送的序号Seq=x的请求进行确认）。

3.第三次握手：客户端在接收到服务端发送的请求和确认信息之后，同样需要告诉服务端已收到信息，tcp报文头中发送标识ACK=1(ACK表示对服务端的连接请求进行应答),序号Seq=x+1，确认号Ack=y+1（表示对服务端发送的序号Seq=y的请求进行确认）

当三次握手都成功的时候，我们发现此时客户端发送的信息服务端能够收到并且服务端发送的信息客户端也能收到，通信双方连接成功。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连 接之前，TCP 连接都将被一直保持下去。
　当客户端和服务端之间的数据传输完毕之后，我们就需要释放连接（一直建立连接会浪费资源）　　 断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”

 1.第一次挥手：客户端向服务端发送断开连接的请求，告诉服务端我这边不需要再请求你的数据了，tcp报文头中发送标识FIN=1（表示客户端请求跟服务端断开连接）,序号Seq=u

 2.第二次挥手：服务端在接收到客户端发送的断开请求后，需告诉客户端已收到请求，tcp报文头中发送标识ACK=1(ACK表示对客户端的断开连接的请求进行应答),序号Seq=v,确认号Ack=u+1（表示对客户端发送的序号Seq=u的请求进行确认）。

 3.第三次挥手：当服务端数据传输完毕之后，向客户端发起断开连接的请求，告诉客户端我这边也不需要再发送数据了，tcp报文头中发送标识FIN=1，ACK=1(FIN表示服务端请求跟客户端断开连接，ACK表示对上一次客户端的断开连接的请求进行应答),序号Seq=w,确认号Ack=u+1（表示对客户端发送的序号Seq=u的请求进行确认）

 4.第四次挥手：客户端接收到服务发送的断开连接请求后，需告诉服务端已收到信息，作出应答，tcp报文头中发送标识ACK=1(ACK表示对服务端的断开连接的请求进行应答),序号Seq=u+1,确认号Ack=w+1（表示对服务端发送的序号Seq=w的请求进行确认）

C# HTTP1.0 1.1 2.0与HTTPS 、TCP/IP协议的UDP与TCP、 Socket介绍与WebSocket

总结

TCP是底层通讯协议，定义的是数据传输和连接方式的规范
      HTTP是应用层协议，定义的是传输数据的内容的规范
      HTTP协议中的数据是利用TCP协议传输的，所以支持HTTP也就一定支持TCP

HTTP支持的是www服务 
      而TCP/IP是协议 
      它是Internet国际互联网络的基础。TCP/IP是网络中使用的基本的通信协议。 
      TCP/IP实际上是一组协议，它包括上百个各种功能的协议，如：远程登录、文件传输和电子邮件等，而TCP协议和IP协议是保证数据完整传输的两个基本的重要协议。

通常说TCP/IP是Internet协议族，而不单单是TCP和IP。

TCP是如何保证可靠传输的

前面我们还说到TCP是可靠的，TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据（假设丢失了）将会被重传。

简单来说，TCP通过这种通信双方相互应答确认和超时重传的机制来保证传输的可靠性。

三.Socket

通常情况下Socket连接就是TCP连接、HTTP底层就是一个Socket、使用TCP协议进行连接时，该Socket连接就是一个TCP连接。HTTP是网络上层协议。底层还是Socket短连接是发送数据时进行联接。发送完关闭 HTTPTCP都是协议，底层都走的Socket

HTTP连接:以HTTP协议为通信协议的TCP连接，HTTP连接是基于TCP连接的，当浏览器需要从服务器获取网页数据的时候，会发出一次HTTP请求。HTTP会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，HTTP会立即将TCP连接断开

Socket连接：基于TCP连接或UDP连接，基于TCP需要先三次握手，可靠传输，基于UDP不需要三次握手不可靠(即时通讯IM)，不可靠传输

HTTP协议：简单的对象访问协议，对应于应用层。Http协议是基于TCP链接的。
TCP协议：对应于传输层
IP协议：对应与网络层
TCP/IP是传输层协议，主要解决数据如何在网络中传输；而Http是应用层协议，主要解决如何包装数据。

Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。HTTP是轿车，提供了封装或者显示数据的具体形式；Socket是发动机，提供了网络通信的能力。像创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议(TCP或UDP),当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

Socket是TCP/IP网络的API，是为了方便大家直接使用更底层协议而存在的一个抽象层。它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议

HTTP是短连接，Socket连接是长连接

1.HTTP的长连接一般就只能坚持一分钟而已，而且是浏览器决定的，你的页面很难控制这个行为。
Socket连接就可以维持很久，几天、数月都有可能，只要网络不断、程序不结束，而且是可以编程灵活控制的。
2.HTTP连接是建立在Socket连接之上。在实际的网络栈中，Socket连接的确是HTTP连接的一部分。但是从HTTP协议看，它的连接一般是指它本身的那部分。

TCP/IP协议栈主要分为四层:应用层、传输层、网络层、数据链路层,

1.Socket是什么呢？

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，
一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。Socket 是对 TCP/IP 协议的封装，Socket 本身并不是协议，而是一个调用接口(API)。

C# HTTP1.0 1.1 2.0与HTTPS 、TCP/IP协议的UDP与TCP、 Socket介绍与WebSocket

2.SOCKET连接与TCP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

由于通常情况下Socket连接就是TCP连接，因此Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但在实际网络应用 中，客户端到服务器之间的通信往往需要穿越多个中间节点，
例如路由器、网关、防火墙等，大部分防火墙默认会关闭长时间处于非活跃状态的连接而导 致 Socket 连接断连，因此需要通过轮询告诉网络，该连接处于活跃状态。

而HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据，然后关闭这个连接。

3.Socket通信方式：

Ø 同步：客户端在发送请求之后必须等到服务器回应之后才可以发送下一条请求。串行运行
Ø 异步：客户端请求之后，不必等到服务器回应之后就可以发送下一条请求。并行运行
套接字模式：
Ø 阻塞：执行此套接字调用时，所有调用函数只有在得到返回结果之后才会返回。在调用结果返回之前，当前进程会被挂起。即此套接字一直被阻塞在网络调用上。
Ø 非阻塞：执行此套接字调用时，调用函数即使得不到得到返回结果也会返回。
套接字工作步骤：
Ø 服务器监听：监听时服务器端套接字并不定位具体客户端套接字，而是处于等待链接的状态，实时监控网络状态
Ø 客户端链接：客户端发出链接请求，要连接的目标是服务器端的套接字。为此客户端套接字必须描述服务器端套接字的服务器地址与端口号。
Ø 链接确认：是指服务器端套接字监听到客户端套接字的链接请求时，它响应客户端链接请求，建立一个新的线程，把服务器端套接字的描述发送给客户端，一旦客户端确认此描述，则链接建立好。而服务器端的套接字继续处于监听状态，继续接受其他客户端套接字请求。

send() 并不立即向网络中传输数据，而是先将数据写入缓冲区中，再由TCP协议将数据从缓冲区发送到目标机器  在TCP/IP等通信中，，数据有可能刚被写入缓冲区就发送到网络，也可能在缓冲区中不断积压，多次写入的数据被一次性发送到网络   接收缓冲区的大小默认8192  设置为100000

阻塞的socket 适用于 一对一  （单个或少量的socket通讯）

非阻塞的socket适用于 大量的socket通讯

断线重连 使用while循环  信号器 阻塞线程

1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;

　　而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。

　　2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。

　　知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，

　　因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，

　　即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率

1）TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）；UDP提供无连接的传输，通信前不需要建立连接。

2）TCP提供可靠的传输（有序，无差错，不丢失，不重复）；UDP提供不可靠的传输。

3）TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组；UDP是面向数据报的传输，没有分组开销。

4.异步通信中长连接问题

如果在指定的时间内（一般为2个小时）没有数据传送，会给对端发送一个Keep-Alive数据，对端如果收到这个数据，回送一个TCP的ACK，确认这个字节已经收到，这样就知道此连接没有被断开。如果一段时间没有收到对方的响应，会进行重试，重试几次后，向对端发一个reset，然后将连接断掉。
　　这是个很常见的问题，产生原因一把由于网络不通畅造成数据延迟接收或发送,可以设置一个心跳包机制，即在程序空闲的时候每隔一定时间就向对端发送一个很小的数据包，然后对端接受到后也发回同样的包，以确保双方都知道连接还在，否则就设置超时，踢掉对端。

send函数用来向TCP连接的另一端发送数据。客户程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答,send的作用是将要发送的数据拷贝到缓冲区，协议负责传输。

recv函数用来从TCP连接的另一端接收数据，当应用程序调用recv函数时，recv先等待s的发送缓冲中的数据被协议传送完毕，然后从缓冲区中读取接收到的内容给应用层。
accept函数用了接收一个连接，内核维护了半连接队列和一个已完成连接队列，当队列为空的时候，accept函数阻塞，不为空的时候accept函数从上边取下来一个已完成连接，返回一个文件描述符。

服务端TCP：创建一个Socket类指定IP和协议(TCP)=>绑定IP和端口号=>开始监听(0为监听无限个客户端 设置的10)=>设置20秒后监听，20秒发送一次=>开启一个线程=>开始调用异步连接

客户端TCP：获取到Socket协议=>绑定IP与端口=>与服务端进行连接  =>开启异步接收模式

C# HTTP1.0 1.1 2.0与HTTPS 、TCP/IP协议的UDP与TCP、 Socket介绍与WebSocket

5.WebSocket

WebSocket协议是基于TCP的一种新的网络协议，和http协议一样属于应用层协议

可以把WebSocket想象成HTTP(应用层)，HTTP和Socket什么关系，WebSocket和Socket就是什么关系。

HTTP 链接分为短链接和长链接，短链接是每次请求都要重新建立TCP链接，TCP又要三次握手才能建立，然后发送自己的信息。即每一个request对应一个response。长链接是在一定的期限内保持TCP连接不断开。客户端与服务器通信，必须要由客户端发起然后服务器返回结果。客户端是主动的，服务器是被动的。

简单的说，WebSocket协议之前，双工通信是通过多个HTTP 链接轮询来实现的，这导致了效率低下。WebSocket解决了这个问题，他实现了多路复用，他是全双工通信。

HTTP 协议有一个缺陷：通信只能由客户端发起，做不到服务器主动向客户端推送信息。

WebSocket 协议 它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种

WebSocket和HTTP一样是一种应用层协议，都是基于TCP传输的， WebSocket是HTML5中的协议，支持持久连接（长），HTTP不支持持久连接（短）