一篇搞懂TCP、HTTP、Socket、Socket链接池

前言:做为一名开发人员咱们常常会听到HTTP协议、TCP/IP协议、UDP协议、Socket、Socket长链接、Socket链接池等字眼,然而它们之间的关系、区别及原理并非全部人都能理解清楚,这篇文章就从网络协议基础开始到Socket链接池,一步一步解释他们之间的关系。linux

七层网络模型程序员

首先从网络通讯的分层模型讲起:七层模型,亦称OSI(Open System Interconnection)模型。自下往上分为:物理层、据链路层、网络层、传输层、会话层、表示层和应用层。全部有关通讯的都离不开它,下面这张图片介绍了各层所对应的一些协议和硬件。数据库

经过上图,我知道IP协议对应于网络层,TCP、UDP协议对应于传输层,而HTTP协议对应于应用层,OSI并无Socket,那什么是Socket,后面咱们将结合代码具体详细介绍。编程

TCP和UDP链接json

关于传输层TCP、UDP协议可能咱们平时碰见的会比较多,有人说TCP是安全的,UDP是不安全的,UDP传输比TCP快,那为何呢,咱们先从TCP的链接创建的过程开始分析,而后解释UDP和TCP的区别。安全

TCP的三次握手和四次分手服务器

咱们知道TCP创建链接须要通过三次握手,而断开链接须要通过四次分手,那三次握手和四次分手分别作了什么和如何进行的。cookie


第一次握手:创建链接。客户端发送链接请求报文段,将SYN位置为1,Sequence Number为x;而后,客户端进入SYN_SEND状态,等待服务器的确认;网络

第二次握手:服务器收到客户端的SYN报文段,须要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,本身本身还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述全部信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;架构

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

完成了三次握手,客户端和服务器端就能够开始传送数据。以上就是TCP三次握手的整体介绍。通讯结束客户端和服务端就断开链接,须要通过四次分手确认。

第一次分手:主机1(可使客户端,也能够是服务器端),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“赞成”你的关闭请求;

第三次分手:主机2向主机1发送FIN报文段,请求关闭链接,同时主机2进入LAST_ACK状态;

第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,而后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段之后,就关闭链接;此时,主机1等待2MSL后依然没有收到回复,则证实Server端已正常关闭,那好,主机1也能够关闭链接了。

能够看到一次tcp请求的创建及关闭至少进行7次通讯,这还不包过数据的通讯,而UDP不需3次握手和4次分手。

TCP和UDP的区别

  1. TCP是面向连接的,虽说网络的不安全不稳定特性决定了多少次握手都不能保证链接的可靠性,但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了链接的可靠性;而UDP不是面向链接的,UDP传送数据前并不与对方创建链接,对接收到的数据也不发送确认信号,发送端不知道数据是否会正确接收,固然也不用重发,因此说UDP是无链接的、不可靠的一种数据传输协议。 
  2. 也正因为1所说的特色,使得UDP的开销更小数据传输速率更高,由于没必要进行收发数据的确认,因此UDP的实时性更好。知道了TCP和UDP的区别,就不难理解为什么采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了,但并不能说QQ的通讯是不安全的,由于程序员能够手动对UDP的数据收发进行验证,好比发送方对每一个数据包进行编号而后由接收方进行验证啊什么的,即便是这样,UDP由于在底层协议的封装上没有采用相似TCP的“三次握手”而实现了TCP所没法达到的传输效率。

问题

关于传输层咱们会常常听到一些问题

1.TCP服务器最大并发链接数是多少?

关于TCP服务器最大并发链接数有一种误解就是“由于端口号上限为65535,因此TCP服务器理论上的可承载的最大并发链接数也是65535”。首先须要理解一条TCP链接的组成部分:客户端IP、客户端端口、服务端IP、服务端端口。因此对于TCP服务端进程来讲,他能够同时链接的客户端数量并不受限于可用端口号,理论上一个服务器的一个端口能创建的链接数是全球的IP数*每台机器的端口数。实际并发链接数受限于linux可打开文件数,这个数是能够配置的,能够很是大,因此实际上受限于系统性能。经过#ulimit -n查看服务的最大文件句柄数,经过ulimit -n xxx 修改 xxx是你想要能打开的数量。也能够经过修改系统参数:

2.为何TIME_WAIT状态还须要等2MSL后才能返回到CLOSED状态?

这是由于虽然双方都赞成关闭链接了,并且握手的4个报文也都协调和发送完毕,按理能够直接回到CLOSED状态(就比如从SYN_SEND状态到ESTABLISH状态那样);可是由于咱们必需要假想网络是不可靠的,你没法保证你最后发送的ACK报文会必定被对方收到,所以对方处于LAST_ACK状态下的Socket可能会由于超时未收到ACK报文,而重发FIN报文,因此这个TIME_WAIT状态的做用就是用来重发可能丢失的ACK报文。

3.TIME_WAIT状态还须要等2MSL后才能返回到CLOSED状态会产生什么问题

通讯双方创建TCP链接后,主动关闭链接的一方就会进入TIME_WAIT状态,TIME_WAIT状态维持时间是两个MSL时间长度,也就是在1-4分钟,Windows操做系统就是4分钟。进入TIME_WAIT状态的通常状况下是客户端,一个TIME_WAIT状态的链接就占用了一个本地端口。一台机器上端口号数量的上限是65536个,若是在同一台机器上进行压力测试模拟上万的客户请求,而且循环与服务端进行短链接通讯,那么这台机器将产生4000个左右的TIME_WAIT Socket,后续的短链接就会产生address already in use : connect的异常,若是使用Nginx做为方向代理也须要考虑TIME_WAIT状态,发现系统存在大量TIME_WAIT状态的链接,经过调整内核参数解决。


编辑文件,加入如下内容:

而后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少许SYN攻击,默认为0,表示关闭;

net.ipv4.tcp_tw_reuse = 1 表示开启重用。容许将TIME-WAIT sockets从新用于新的TCP链接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1 表示开启TCP链接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的TIMEOUT时间。

HTTP协议

关于TCP/IP和HTTP协议的关系,网络有一段比较容易理解的介绍:“咱们在传输数据时,能够只使用(传输层)TCP/IP协议,可是那样的话,若是没有应用层,便没法识别数据内容。若是想要使传输的数据有意义,则必须使用到应用层协议。应用层协议有不少,好比HTTP、FTP、TELNET等,也能够本身定义应用层协议。

HTTP协议即超文本传送协议(Hypertext Transfer Protocol ),是Web联网的基础,也是手机联网经常使用的协议之一,WEB使用HTTP协议做应用层协议,以封装HTTP文本信息,而后使用TCP/IP作传输层协议将它发到网络上。

因为HTTP在每次请求结束后都会主动释放链接,所以HTTP链接是一种“短链接”,要保持客户端程序的在线状态,须要不断地向服务器发起链接请求。一般 的作法是即时不须要得到任何数据,客户端也保持每隔一段固定的时间向服务器发送一次“保持链接”的请求,服务器在收到该请求后对客户端进行回复,代表知道 客户端“在线”。若服务器长时间没法收到客户端的请求,则认为客户端“下线”,若客户端长时间没法收到服务器的回复,则认为网络已经断开。

下面是一个简单的HTTP Post application/json数据内容的请求:

关于Socket(套接字)

如今咱们了解到TCP/IP只是一个协议栈,就像操做系统的运行机制同样,必需要具体实现,同时还要提供对外的操做接口。就像操做系统会提供标准的编程接口,好比Win32编程接口同样,TCP/IP也必须对外提供编程接口,这就是Socket。如今咱们知道,Socket跟TCP/IP并无必然的联系。Socket编程接口在设计的时候,就但愿也能适应其余的网络协议。因此,Socket的出现只是能够更方便的使用TCP/IP协议栈而已,其对TCP/IP进行了抽象,造成了几个最基本的函数接口。好比create,listen,accept,connect,read和write等等。

不一样语言都有对应的创建Socket服务端和客户端的库,下面举例Nodejs如何建立服务端和客户端:

服务端:

服务监听9000端口

下面使用命令行发送http请求和telnet

注意到curl只处理了一次报文。

客户端

Socket长链接

所谓长链接,指在一个TCP链接上能够连续发送多个数据包,在TCP链接保持期间,若是没有数据包发送,须要双方发检测包以维持此链接(心跳包),通常须要本身作在线维持。 短链接是指通讯双方有数据交互时,就创建一个TCP链接,数据发送完成后,则断开此TCP链接。好比Http的,只是链接、请求、关闭,过程时间较短,服务器如果一段时间内没有收到请求便可关闭链接。其实长链接是相对于一般的短链接而说的,也就是长时间保持客户端与服务端的链接状态。

一般的短链接操做步骤是:

链接→数据传输→关闭链接;

而长链接一般就是:

链接→数据传输→保持链接(心跳)→数据传输→保持链接(心跳)→……→关闭链接;

何时用长链接,短链接

长链接多用于操做频繁,点对点的通信,并且链接数不能太多状况,。每一个TCP链接都须要三步握手,这须要时间,若是每一个操做都是先链接,再操做的话那么处理 速度会下降不少,因此每一个操做完后都不断开,次处理时直接发送数据包就OK了,不用创建TCP链接。例如:数据库的链接用长链接, 若是用短链接频繁的通讯会形成Socket错误,并且频繁的Socket建立也是对资源的浪费。

什么是心跳包为何须要

心跳包就是在客户端和服务端间定时通知对方本身状态的一个本身定义的命令字,按照必定的时间间隔发送,相似于心跳,因此叫作心跳包。网络中的接收和发送数据都是使用Socket进行实现。可是若是此套接字已经断开(好比一方断网了),那发送数据和接收数据的时候就必定会有问题。但是如何判断这个套接字是否还可使用呢?这个就须要在系统中建立心跳机制。其实TCP中已经为咱们实现了一个叫作心跳的机制。若是你设置了心跳,那TCP就会在必定的时间(好比你设置的是3秒钟)内发送你设置的次数的心跳(好比说2次),而且此信息不会影响你本身定义的协议。也能够本身定义,所谓“心跳”就是定时发送一个自定义的结构体(心跳包或心跳帧),让对方知道本身“在线”,以确保连接的有效性。

实现:

服务端:

服务端输出结果:

客户端代码:


客户端输出结果:

定义本身的协议

若是想要使传输的数据有意义,则必须使用到应用层协议好比Http、Mqtt、Dubbo等。基于TCP协议上自定义本身的应用层的协议须要解决的几个问题:

  1. 心跳包格式的定义及处理
  2. 报文头的定义,就是你发送数据的时候须要先发送报文头,报文里面能解析出你将要发送的数据长度
  3. 你发送数据包的格式,是json的仍是其余序列化的方式

下面咱们就一块儿来定义本身的协议,并编写服务的和客户端进行调用:

定义报文头格式: length:000000000xxxx; xxxx表明数据的长度,总长度20,举例子不严谨。

数据序列化方式:JSON。

服务端:


日志打印:

客户端

日志打印:

这里能够看到一个客户端在同一个时间内处理一个请求能够很好的工做,可是想象这么一个场景,若是同一时间内让同一个客户端去屡次调用服务端请求,发送屡次头数据和内容数据,服务端的data事件收到的数据就很难区别哪些数据是哪次请求的,好比两次头数据同时到达服务端,服务端就会忽略其中一次,然后面的内容数据也不必定就对应于这个头的。因此想复用长链接并能很好的高并发处理服务端请求,就须要链接池这种方式了。

Socket链接池

什么是Socket链接池,池的概念能够联想到是一种资源的集合,因此Socket链接池,就是维护着必定数量Socket长链接的集合。它能自动检测Socket长链接的有效性,剔除无效的链接,补充链接池的长链接的数量。从代码层次上实际上是人为实现这种功能的类,通常一个链接池包含下面几个属性:

  1. 空闲可以使用的长链接队列
  2. 正在运行的通讯的长链接队列
  3. 等待去获取一个空闲长链接的请求的队列
  4. 无效长链接的剔除功能
  5. 长链接资源池的数量配置
  6. 长链接资源的新建功能

场景: 一个请求过来,首先去资源池要求获取一个长链接资源,若是空闲队列里面有长链接,就获取到这个长链接Socket,并把这个Socket移到正在运行的长链接队列。若是空闲队列里面没有,且正在运行的队列长度小于配置的链接池资源的数量,就新建一个长链接到正在运行的队列去,若是正在运行的不下于配置的资源池长度,则这个请求进入到等待队列去。当一个正在运行的Socket完成了请求,就从正在运行的队列移到空闲的队列,并触发等待请求队列去获取空闲资源,若是有等待的状况。

下面简单介绍Node.js的一个通用链接池模块:generic-pool。

主要文件目录结构

初始化链接池

使用链接池

下面链接池的使用,使用的协议是咱们以前自定义的协议。


日志打印:

这里看到前面两个请求都创建了新的Socket链接 socket_pool 127.0.0.1 9000 connect,定时器结束后从新发起两个请求就没有创建新的Socket链接了,直接从链接池里面获取Socket链接资源。

源码分析

发现主要的代码就位于lib文件夹中的Pool.js
构造函数:
lib/Pool.js

能够看到包含以前说的空闲的资源队列,正在请求的资源队列,正在等待的请求队列等。

下面查看 Pool.acquire 方法

lib/Pool.js

上面的代码就按种状况一直走下到最终获取到长链接的资源,其余更多代码你们能够本身去深刻了解。

做者简介:6年服务端开发经验,负责过初创企业项目从零到高并发访问的技术方案演变及开发部署,积累了必定平台开发和高并发高可用经验,如今负责公司微服务框架下网关层的架构及开发。

相关文章
相关标签/搜索