一、Socket简介

1.1 socket是什么

socket套接字：socket起源于Unix，而Unix/Linux基本哲学之一就是“一切皆文件”，都可以用“打开open –> 读写write/read –> 关闭close”模式来操作。

Socket就是该模式的一个实现，socket即是一种特殊的文件，一些socket函数就是对其进行的操作（读/写IO、打开、关闭）.

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

注意：其实socket也没有层的概念，它只是一个facade设计模式的应用，让编程变的更简单。是一个软件抽象层。在网络编程中，我们大量用的都是通过socket实现的。

1.5 socket使用场景

（一）socket的使用场景：

如：浏览器进程与web服务器进程通信；

如：QQ进程与好友的QQ进程通信；

（二）本地的进程通信：

本地的进程间通信（IPC）有很多种方式，但可以总结为下面3类：

1.消息传递（管道、FIFO、消息队列）

2.同步（互斥量、条件变量、读写锁、文件和写记录锁、信号量）

3.共享内存（匿名的和具名的）

（三）标识一个进程：

在本地可以通过进程PID来唯一标识一个进程，但是在网络中这是行不通的。

网络层的“ip地址”可以唯一标识网络中的主机，而传输层的“协议+端口”可以唯一标识主机中的应用程序（进程）。这样利用三元组（ip地址，协议，端口）就可以标识网络的进程了。

（四）网络上的进程通信：

使用TCP/IP协议的应用程序通常采用应用编程接口：UNIX  BSD的套接字（socket)

1.6 socket与http的比较

HTTP是基于应用层，socket是基于传输层（tcp/udp）

我们通常所用的socket协议是基于TCP协议

TCP是面向连接的协议，UDP是面向非连接的协议

TCP协议一般应用场景：能为应用程序提供可靠的通信连接，使一台计算机发出的字节流无差错地发往网络上的其他计算机，对可靠性要求高的数据通信系统往往使用TCP协议传输数据

UDP协议一般应用场景：适用于一次只传送少量数据、对可靠性要求不高的应用环境

1.7 socket连接过程

（1）建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。

（2）套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。

客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。

连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

1.8 socket连接与TCP连接

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

1.9 Socket连接与HTTP连接

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

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

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给 客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，因此，客户端定时向服务器端发送连接请求，不仅可以 保持在线，同时也是在“询问”服务器是否有新的数据，如果有就将数据传给客户端。

五、Socket的其他理解

5.1 Socket和TCP/IP

　　最近在看《TCP/IP详解 卷1：协议》，关于TCP/IP我觉得讲解的非常详细，我做了点摘抄，可以大致看看，非常建议大家阅读下这本书。通常TCP/IP分为四层：

也就是说Socket实际上是归属于应用层，使用的事运输层的TCP，使用SocketServer监听的端口，也是可以被Telnet连接的。可以看下面两行代码：

ServerSocket server = new ServerSocket(port);

Socket socket = server.accept();

　　在什么情况获取到这个Socket呢，通过理论加测试，结论是在三次握手操作后，系统才会将这个连接交给应用层，ServerSocket 才知道有一个连接过来了。那么系统当接收到一个TCP连接请求后，如果上层还没有接受它（假如SocketServer循环处理Socket，一次一个），那么系统将缓存这个连接请求，既然是缓存那么就是有限度的，书上介绍的是缓存3个，但是经过我的本机测试是50个，也就是说，系统将会为应用层的Socket缓存50和TCP连接（这是和系统底层有关系的），当超过指定数量后，系统将会拒绝连接。

　　假如缓存的TCP连接请求发送来数据，那么系统也会缓存这些数据，等待SocketServer获得这个连接的时候一并交给它，这个会在后期学习NIO进行详解。

　　换句话说，系统接收TCP连接请求放入缓存队列，而SocketServer从缓存队列获取Socket。

　　而上面例子中的为了让服务端知道发送完消息的，关闭输出流的操作：

socket.shutdownOutput();

　　其实是对应着四次挥手的第一次：

　　也就是上面说的主动关闭，FIN_WAIT_1，这样服务端就能得知客户端发送完消息，此时服务端可以选择关闭连接，也可以选择发送数据后关闭连接：

　　这就是TCP所说的半关闭。其实很多知识都是想通的，多学点基础知识还是有必要的。

5.2 Socket和RMI

　　RMI基础知识就不多介绍了（后续会写，敬请期待），现在假定你对RMI有所了解，那么一般就会对这两种技术有所比较。或者说在应用的时候就会想用那种技术比较好。

　　RMI全称：Remote Method Invocation－远程方法调用，通过名字其实就能对这种技术有个初步的了解。现在我就简单说说我对这两种技术的想法。

　　这个待写，等我写完RMI博客的时候补上，那时候会更细致的了解下。

5.3 Socket与DatagramSocket

　　这一段涉及到UDP，依然和上面一样，后续会补上。

5.4 Socket拆包和黏包

　　使用Socket通信的时候，或多或少都听过拆包和黏包，如果没听过而去贸然编程那么偶尔就会碰到一些莫名其妙的问题，所有有这方面的知识还是比较重要的，至少知道怎么发生，怎么防范。

　　现在先简单说明下拆包和黏包的原因：

[if !supportLists]· [endif]拆包：当一次发送（Socket）的数据量过大，而底层（TCP/IP）不支持一次发送那么大的数据量，则会发生拆包现象。

[if !supportLists]· [endif]黏包：当在短时间内发送（Socket）很多数据量小的包时，底层（TCP/IP）会根据一定的算法（指Nagle）把一些包合作为一个包发送。

　　首先可以明确的是，大部分情况下我们是不希望发生拆包和黏包的（如果希望发生，什么都去做即可），那么怎么去避免呢，下面进行详解？

5.4.1黏包

　　首先我们应该正确看待黏包，黏包实际上是对网络通信的一种优化，假如说上层只发送一个字节数据，而底层却发送了41个字节，其中20字节的I P首部、 20字节的T C P首部和1个字节的数据，而且发送完后还需要确认，这么做浪费了带宽，量大时还会造成网络拥堵。当然它还是有一定的缺点的，就是因为它会合并一些包会导致数据不能立即发送出去，会造成延迟，如果能接受（一般延迟为200ms），那么还是不建议关闭这种优化，如果因为黏包会造成业务上的错误，那么请改正你的服务端读取算法（协议），因为即便不发生黏包，在服务端缓存区也可能会合并起来一起提交给上层，推荐使用长度+类型+数据模式。

　　如果不希望发生黏包，那么通过禁用TCP_NODELAY即可，Socket中也有相应的方法：

void setTcpNoDelay(boolean on)

　　通过设置为true即可防止在发送的时候黏包，但是当发送的速率大于读取的速率时，在服务端也会发生黏包，即因服务端读取过慢，导致它一次可能读取多个包。

5.4.2拆包

　　这个问题应该引起重视，在TCP/IP详解中说过：最大报文段长度（MSS）表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的 MSS。客户端会尽量满足服务端的要求且不能大于服务端的MSS值，当没有协商时，会使用值536字节。虽然看起来MSS值越大越好，但是考虑到一些其他情况，这个值还是不太好确定，具体详见《TCP/IP详解 卷1：协议》。

　　如何应对拆包，其实在上面2.3节已经介绍过了，那就是如何表明发送完一条消息了，对于已知数据长度的模式，可以构造相同大小的数组，循环读取，示例代码如下：

int length=1024;//这个是读取的到数据长度，现假定1024byte[] data=new byte[1024];int readLength=0;while(readLength<length){

    int read = inputStream.read(data, readLength, length-readLength);

    readLength+=read;

}

这样当循环结束后，就能读取到完整的一条数据，而不需要考虑拆包了。

六、WebSocket

6.1 websocket是什么

WebSocket协议是基于TCP的一种新的网络协议。它实现了浏览器与服务器全双工(full-duplex)通信——允许服务器主动发送信息给客户端。

WebSocket用于在Web浏览器和服务器之间进行任意的双向数据传输的一种技术。WebSocket协议基于TCP协议实现，包含初始的握手过程，以及后续的多次数据帧双向传输过程。其目的是在WebSocket应用和WebSocket服务器进行频繁双向通信时，可以使服务器避免打开多个HTTP连接进行工作来节约资源，提高了工作效率和资源利用率。

6.2 webSocket为什么要用

1）一直以来，HTTP协议是无状态、单向通信的，即客户端请求一次，服务器回复一次。如果想让服务器消息及时下发到客户端，需要采用类似于轮询的机制，即客户端定时频繁的向服务器发出请求，这样效率很低，而且HTTP数据包头本身的字节量较大，浪费了大量带宽和服务器资源；

2）为提高效率，出现了AJAX/Comet技术，它实现了双向通信且节省了一定带宽，但仍然需要发出请求，本质上仍然是轮询；

3）新一代HTML标准HTML5推出了WebSocket技术，它使客户端和服务器之间能通过HTTP协议建立TCP连接，之后便可以随时随地进行双向通信，且交换的数据包头信息量很小；

6.3 webSocket优点

1）通过第一次HTTP Request建立了连接之后，后续的数据交换都不用再重新发送HTTP Request，节因此它省了带宽资源；

2) WebSocket的连接是双向通信的连接，在同一个TCP连接上，既可以发送，也可以接收;

3)具有多路复用的功能(multiplexing)，也就是说几个不同的URI可以复用同一个WebSocket连接。

6.4 websocket的作用

（1）轮询：

轮询呢，顾名思义就是每隔几一段时间去做一件事情，这里就是每隔一定的时间，客户端就向web服务器发一次请求，请求当前的新数据。

轮询却是是一个合理的方案，但是有时候他的效率就不是很高，因为轮询就意为这要向服务器发起请求，要不断的建立新的连接，而这样做只是为了知道是否有新的数据，试想一下如果有成千上万的用户都这样轮询，时间一长服务器受得了吗？

（2）long poll：

long poll其实原理跟 轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。

（3）websocket：终于到主角了，，

通过上面两个对话，我们可以看出，这两种方式都不是最好的，需要很多资源，也浪费了很多的带宽。

况且HTTP还是一个状态协议。

6.5 webSocket如何使用

在支持WebSocket的浏览器中，创建Socket之后，通过onopen、onmessage、onclose、onerror四个事件的实现来处理Socket的响应；

6.6 webSocket处理过程

（1）创建ws对象以及通道：客户端建立socket对象并连接服务器端对象

（2）通道建立成功需要执行的动作:onopen事件

（3）发送消息:send方法

（4）接收消息:onmessage事件

（5）关闭通道:onclose事件

（6）错误处理:onerror事件

6.7 webSocket什么情况下使用

如果游戏需要同时支持手机端、Web端，那毫无疑问应该使用WebSocket，现在各个平台都提供了相应的WebSocket实现。如果游戏不需要支持Web端，且对实时性要求比较高，如多人射击、MMORPG之类，那么使用TCP/UDP结合的原生Socket会比较好。

6.8 websocket使用场景

（1）社交订阅

对社交类的应用的一个裨益之处就是能够即时的知道你的朋友正在做什么。虽然听起来有点可怕，但是我们都喜欢这样做。你不会想要在数分钟之后才能知道一个家庭成员在馅饼制作大赛获胜或者一个朋友订婚的消息。你是在线的，所以你的订阅的更新应该是实时的。

（2）多玩家游戏

网络正在迅速转变为游戏平台。在不使用插件（我指的是Flash）的情况下，网络开发者现在可以在浏览器中实现和体验高性能的游戏。无论你是在处理DOM元素、CSS动画，HTML5的canvas或者尝试使用WebGL，玩家之间的互动效率是至关重要的。我不想在我扣动扳机之后，我的对手却已经移动位置。

（3）协同编辑/编程

我们生活在分布式开发团队的时代。平时使用一个文档的副本就满足工作需求了，但是你最终需要有一个方式来合并所有的编辑副本。版本控制系统，比如Git能够帮助处理某些文件，但是当Git发现一个它不能解决的冲突时,你仍然需要去跟踪人们的修改历史。通过一个协同解决方案，比如WebSocket，我们能够工作在同一个文档，从而省去所有的合并版本。这样会很容易看出谁在编辑什么或者你在和谁同时在修改文档的同一部分。

（4）点击流数据

分析用户与你网站的互动是提升你的网站的关键。HTTP的开销让我们只能优先考虑和收集最重要的数据部分。然后，经过六个月的线下分析，我们意识到我们应该收集一个不同的判断标准——一个看起来不是那么重要但是现在却影响了一个关键的决定。与HTTP请求的开销方式相比，使用Websocket，你可以由客户端发送不受限制的数据。想要在除页面加载之外跟踪鼠标的移动？只需要通过WebSocket连接发送这些数据到服务器，并存储在你喜欢的NoSQL数据库中就可以了（MongoDB是适合记录这样的事件的）。现在你可以通过回放用户在页面的动作来清楚的知道发生了什么。

（5）股票基金报价

金融界瞬息万变——几乎是每毫秒都在变化。我们人类的大脑不能持续以那样的速度处理那么多的数据，所以我们写了一些算法来帮我们处理这些事情。虽然你不一定是在处理高频的交易，但是，过时的信息也只能导致损失。当你有一个显示盘来跟踪你感兴趣的公司时，你肯定想要随时知道他们的价值，而不是10秒前的数据。使用WebSocket可以流式更新这些数据变化而不需要等待。

（6）体育实况更新

现在我们开始讨论一个让人们激情澎湃的愚蠢的东西——体育。我不是运动爱好者，但是我知道运动迷们想要什么。当爱国者在打比赛的时候，我的妹夫将会沉浸于这场比赛中而不能自拔。那是一种疯狂痴迷的状态，完全发自内心的。我虽然不理解这个，但是我敬佩他们与运动之间的这种强烈的联系，所以，最后我能做的就是给他的体验中降低延迟。如果你在你的网站应用中包含了体育新闻，WebSocket能够助力你的用户获得实时的更新。

（7）多媒体聊天

视频会议并不能代替和真人相见，但当你不能在同一个屋子里见到你谈话的对象时，视频会议是个不错的选择。尽管视频会议私有化做的“不错”，但其使用还是很繁琐。我可是开放式网络的粉丝，所以用WebSockets getUserMedia API和HTML5音视频元素明显是个不错的选择。WebRTC的出现顺理成章的成为我刚才概括的组合体，它看起来很有希望，但其缺乏目前浏览器的支持，所以就取消了它成为候选人的资格。

（8）基于位置的应用

越来越多的开发者借用移动设备的GPS功能来实现他们基于位置的网络应用。如果你一直记录用户的位置(比如运行应用来记录运动轨迹)，你可以收集到更加细致化的数据。如果你想实时的更新网络数据仪表盘(可以说是一个监视运动员的教练)，HTTP协议显得有些笨拙。借用WebSocket TCP链接可以让数据飞起来。

（9）在线教育

上学花费越来越贵了，但互联网变得更快和更便宜。在线教育是学习的不错方式，尤其是你可以和老师以及其他同学一起交流。很自然，WebSockets是个不错的选择，可以多媒体聊天、文字聊天以及其它优势如与别人合作一起在公共数字黑板上画画..

6.9 webSocket原理

”Upgrade:WebSocket”表示这是一个特殊的 HTTP 请求，请求的目的就是要将客户端和服务器端的通讯协议从 HTTP 协议升级到 WebSocket 协议。在请求中的“Sec-WebSocket-Key”是随机的，服务器端会用这些数据来构造出一个SHA-1的信息摘要。把“Sec-WebSocket-Key”加上一个魔幻字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”。使用SHA-1加密，之后进行BASE-64编码，将结果做为“Sec-WebSocket-Accept”头的值，返回给客户端。以表明服务器端获取了客户端的请求，同意创建 WebSocket 连接。一旦连接建立，客户端和服务器端就可以通过这个通道双向传输数据了。

6.10 webSocket协议

WebSocket是一种协议，与HTTP协议一样位于应用层，都是TCP/IP协议的子集。HTTP协议是单向通信协议，只有客户端发起HTTP请求，服务端才会返回数据。而WebSocket协议是双向通信协议，在建立连接之后，客户端和服务器都可以主动向对方发送或接受数据。WebSocket协议建立的前提需要借助HTTP协议，建立连接之后，持久连接的双向通信就与HTTP协议无关了。

WebSocket协议的目标是在一个独立的持久连接上提供全双工双向通信。客户端和服务器可以向对方主动发送和接受数据。在JS中创建WebSocket后，会有一个HTTP请求发向浏览器以发起请求。在取得服务器响应后，建立的连接会使用HTTP升级将HTTP协议转换为WebSocket协议。也就是说，使用标准的HTTP协议无法实现WebSocket，只有支持那些协议的专门浏览器才能正常工作。

由于WebScoket使用了自定义协议，所以URL与HTTP协议略有不同。未加密的连接为ws://，而不是http://。加密的连接为wss://，而不是https://。

6.11 WebSocket与HTTP、TCP的关系

WebSocket和HTTP都属于应用层协议，且都是基于TCP的，它们的send函数最终也是通过TCP系统接口来做数据传输。那么WebSocket和HTTP的关系呢？WebSocket在建立握手连接时，数据是通过HTTP协议传输的，但是在连接建立后，真正的数据传输阶段则不需要HTTP协议的参与。它们之间的关系如下图