TCP和UDP的区别

UDP
TCP
是否连接
无连接
面向连接
是否可靠
不可靠传输,不使用流量控制和拥塞控制
可靠传输,使用流量控制和拥塞控制
连接对象个数
支持一对一,一对多,多对一和多对多交互通信
只能是一对一通信
传输方式
面向报文
面向字节流
首部开销
首部开销小,仅8字节
首部最小20字节,最大60字节
适用场景
适用于实时应用(IP电话、视频会议、直播等)
适用于要求可靠传输的应用,例如文件传输

快速理解WebSocket 协议

在了解WebSocket之前需要先了解socket是什么。
首先要知道,现在任何的网络协议都是基于socket协议。
socket的中文翻译叫“套接字”,然而这个中文翻译非常晦涩难懂,很难解释清楚。
其实socket直接翻译过来的含义是插座的意思。
我的个人理解就是2个人互相发送文件的时候,如果发1个文件就在插座上插1条线,再发另外1个文件就再插1条线。不管是发文件还是收文件,都是通过插座上面的线来传输,这个线就叫“线程”。而插座就是为了“创建”和“关闭”这些“线程”而设计的。

先看一下socket的流程图

我们发现socket的流程非常简单,主要分三步
1.创建
2.收发
3.关闭
程序中创建socket协议通常有两个参数,第一个为ip协议规范(ipv4/ipv6),第二个为协议类型(TCP/UPD)
例如PHP的socket_create方法,socket_create ( int $domain , int $type , int $protocol ) : resource
具体参数对应的含义请查看文档

接下来正式说明什么是WebSocket
定义:WebSocket是一种在单个TCP连接上进行全双工通信(同时双向发送数据)的协议。浏览器和服务器只需要完成一次握手,两者之间就直接可以创建持久性的连接,并进行双向数据传输。
http协议url地址是长这样http://example.com:/some/path
而websocket协议的地址是这样ws://example.com:80/some/path

在客户端使用WebSocket非常简单

var ws = new WebSocket("wss://echo.websocket.org");

ws.onopen = function(evt) { //连接成功后的回调
console.log("Connection open ...");
ws.send("Hello WebSockets!");
};

ws.onmessage = function(evt) { //接收数据
console.log( "Received Message: " + evt.data);
ws.close();
};

ws.send('your message’); // 发送数据

ws.onclose = function(evt) { // 连接关闭后的回调
console.log("Connection closed.");
};

服务端使用WebSocket如果是NodeJS常用的就是
Socket.IO
如果用java就是Tomcat7.0以上
PHP用swoole

WebSocket协议的优点是什么?
最大的优点就是在实现即时通讯的方法上面更节省资源。
先说下面两种及时通讯方式的缺点
HTTP轮询:因为是单向通信,1次请求对应一次响应,然后关闭连接。如果服务端没有最新信息,那么就有大量的空响应回来,也就是无意义的请求,浪费资源。
Socket长连接:一旦建立连接就不会关闭,如果服务端没有最新数据,那么线程被占用,却没有收发数据,比轮询的方式还浪费资源。
WS协议:先用HTTP的方式握手建立连接,然后用socket的长连接方式保持通话,再用HTTP的方式挥手关闭连接。结合了上面两种方式的优点,是目前的最优手段。

快速理解TCP三次握手和四次挥手

三次握手:
例如我们打电话的时候先要确认双方身份。
假设客户端是儿子,服务端是妈妈
儿子:喂,妈妈在吗?
妈妈:我在,是儿子给我打电话吗?
儿子:对,是我啊,可以聊了。
如果双方确认不了身份就挂机不聊了。

TCP协议包每种标识对应的含义
* SYN(synchronous),建立联机。
* ACK(acknowledgement),确认。
* PSH(push),传输。
* FIN(finish),结束。
* RST(reset),重置。
* URG(urgent),紧急。

3次握手的过程:
1 client 发送 SYN seq=x 请求与服务器建立连接
2 server 发送 ACK=x+1,SYN seq=y 确认请求,请求与客户端建立连接
3 client 发送 ACK=y+1 确认请求

确认请求的方式就是把syn里面的x的值加1。

注意!!TCP协议每次传输数据包前面都会先再带一个ACK确认包,告诉对方我已经收到上次的数据包了;这也是TCP和UDP最大的区别。
TCP如果没有收到确认包,就会隔一段时间再发送一次数据,来保证每次传输的数据都是完整的。而UDP中没有,所以TCP稳定。
为什么要进行3次握手,因为客户端在没有收到响应的情况下会因为连接超时从而断开连接,服务端为了不浪费资源,发现客户端超时之后就会关闭连接了。

四次挥手:
三次握手是为了建立连接,而四次挥手是为了关闭连接,如果理解三次握手,那么四次挥手就非常好理解了,原理差不多。
先看两张图

1 客户端先发送关闭请求包FIN,进入等待状态1
2 服务端收到关闭且请求后,先发送确认收到的包ACK,进入关闭等待状态。这时候客户端先收到了确认包,进入等待状态2.
3 服务端也发送一个请求关闭的包FIN,进入最后确认状态
4 客户端收到服务端的关闭请求后发送最终确认包ACK给服务端,然后进入等待计时器,在计时器结束后,进入关闭状态,服务端收到最终确认包之后立即进入关闭状态。

为何要四次分手呢?

1 当客户端发出FIN报文段时,只是表示已经没有数据要发送了。但是,这个时候主客户端还是可以接受来自服务器的数据;
2 当服务器返回ACK报文段时,表示它已经知道客户端没有数据发送了,但是还是可以往客户端推送数据包;
3 当服务器也发送了FIN报文段时,就会告诉客户端,我也没有数据要发送了;
4 再双方都确认之后彼此就会愉快的中断这次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: 表示连接中断。

快速理解HTTPS协议

先知道HTTP协议是明文发送,比如抓包工具里面可以看到账号密码;
HTTPS多了一层SSL协议,用来加密信息,原理如下:

1. 服务器先发送一个安全证书,告诉客户端与这个服务器通信是安全的
2. 请求信息前,服务器会生成2把钥匙和一个空箱子。
3. 然后把空箱子和其中1把钥匙发给客户端
4. 客户端把信息放入箱子,锁上再发给服务器,这样2边都有钥匙,就都可以访问箱子里面的内容了。

再传输的过程中,就算箱子被截取了,因为没有钥匙,就很难获取箱子里面的数据。以现在的黑客技术,破解箱子也是非常有难度的

解决npm 全局安装某些包时报权限相关的错误

今天在Mac系统下全局安装node-sass总是报权限方面的错误。

错误信息:gyp ERR! stack Error: EACCES: permission denied, mkdir ‘/usr/local/lib/node_modules/node-sass/.node-gyp’

字面上大概意思就是没有操作这个目录的权限,然后我尝试手动把/usr/local/lib/node_modules的目录权限改成777也不行。

最后经过网上各种搜索解决办法,找到了根本原因是:

npm 出于安全考虑不支持以 root 用户运行,即使你用 root 用户身份运行了,npm 会自动转成一个叫 nobody 的用户来运行,而这个用户几乎没有任何权限。这样的话如果你脚本里有一些需要权限的操作,比如写文件(尤其是写 /root/.node-gyp),就会崩掉了。
为了避免这种情况,要么按照 npm 的规矩来,专门建一个用于运行 npm 的高权限用户;要么加 –unsafe-perm 参数,这样就不会切换到 nobody 上,运行时是哪个用户就是哪个用户,即使是 root。

知道了问题的原因就可以正确的解决了,所以把安装命令后面加上这个–unsafe-perm 参数即可。
完整的全局安装node-sass命令为:
sudo npm i -g node-sass --unsafe-perm