###第1篇转载###

我们经常听到"建立TCP连接"，"服务器的连接数量有限"等，但仔细一想，连接究竟是个什么东西，是和电话一样两端连起一根线？似乎有点抽象不是么？
1.久违的分组交换网络

似乎这个概念只有在学校里学计算机网络才能接触到，但不过今天的话题其实和它离不开关系。我们知道最早的电话网络是以很容易理解的形式存在的，就是单纯的一根线加两端的设备，设备之间所沟通的所有信息都通过一根特定的电缆来回传输，如下图：



这样的连接是我们特别好理解的，搭起两边的线，就是一个连接嘛！但是，我们讨论的是计算机网络！(严肃脸)，计算机网络中两个设备节点是如何通信？



计算机网络采取分组交换技术，什么意思呢？就是我有【一块数据】要发给对方小苍，那我会把这【一块数据】分成N份【单位数据】，分别发出去，而每份【单位数据】走哪条路是不一定的，但是这些【单位数据】总要全部达到小苍手里，小苍再根据【单位数据】里记录的序号拼接起来，组成完整的【一块数据】。这就是分组的意思所在。
2.协议和协议实现

上面不小心把TCP的大体实现给说了，实际上在具体的应用中，光有大体思路是不行的，还有很多细节问题，需要两个设备之间提前约定好协议，才能协同完成通信。举个例子：A向B发了10份【单位数据】，而B其实只收到9份【单位数据】，怎么办？
TCP协议大家都应该是知道的，但协议只是想法，真正起作用的是在路由节点和设备节点上的协议软件，是运行在设备上的具体执行者，它根据协议指导，对具体数据进行控制和操作。这儿就不往下展开了。
认识到协议和协议软件这一点非常重要，因为连接的限制恰恰就是受软件在设备中资源分配的影响的。
3.连接的真面目

上面说的第一种电话网络，如果两个设备搭设了一条线，那么两个电话就一定确定对方在线，因为他俩独享一条实时存在的线。但计算机网络的连接呢？



向上面的图一样(图里不深究TCP，仅仅用来说明连接大体过程)，其实他们俩并不能确保对方就是在线，只是通过几番确认，认为对方一直会在。而如果确认了对方存在，那么就会为以后的对话通讯分配内存、CPU处理时间等资源，每个设备都会在本地去维持这么一个状态，来告诉自己是有一个连接的，这些设备所花的资源和维护的状态，就是连接。而整个网络是不会记录有着一条连接的，所以说连接只是记录在各个设备的一个状态信息。
那么，到现在我们知道了，连接其实并不是所谓的有一根电线连起两个设备，而是两方确认了一下对方的存在后，自己在本地记录的状态。那么下面可以讨论一下以前迷惑重重的概念了。
4.为什么服务器都有连接数量的限制？

这里只做讨论。我认为是有两点：
物理带宽的限制，决定了一个时间段内发起连接的数据包不会超过某个数，造成了设备的链接数量的限制。

维持连接需要分配内存等资源，设备的资源有限，决定了一定有个最大连接数的极限。
5.待续

通过连接往外延伸的话题不少，先到此为止吧，有时间再补。
###第2篇转载###

这个问题说实话困扰了我接近2年时间，我们找到的所有资料上都写着，TCP是面向连接的服务，所有要通过TCP进行通信的应用都要先建立连接才能通信，在通信完毕之后要记得关闭连接。直到前不久才突然搞明白，这里记录下来，文章写得也许不够特别准确，但是我觉得对于理解整个建立过程是足够了。
结论

这里先说结论，连接实际上是操作系统内核的一种数据结构，称为TCP控制块（TCB），对于linux而言是tcp_sock结构。不光连接，连数据包也是由一个数据结构来控制，linux里面称为sk_buff结构。
为什么需要TCB

当应用希望写数据时，并不是直接向网卡驱动发数据，而是先放入到一个缓冲区中，然后根据一定算法（达到一定数量或者调用flush之后），缓冲区中的数据就经发送到网卡中了（这里说的不准确，实际上，是网卡主动从缓冲区中拷贝出来的，但并不影响我们理解）。
当网卡收到数据时，数据包要先经过如下几步：
数据包要先经过网卡校验正确与否。

数据链路层根据报头的类型传给不同的上层类型（IP层或者其他），并移除了数据链路层报头。

IP层也需要先校验，然后根据IP报头选择不同的类型（TCP或者UDP），然后移除IP层报头，并将剩余的数据发送到相应的处理程序（tcp或udp)

到了tcp层，处理程序此时根据tcp首部中的端口号选择一个socket，并将其载荷数据拷贝进去。

所以到这里，我们就应该知道，每个socket必须要有自己独立的发送缓冲区和接收缓冲区，并且还应该还有其他控制结构或者标示结构，这就构成了TCB，没有TCB，接收到的数据根本就不知道要传递到哪里？
对了，有一句话在这里没说，就是网卡收到的数据是以数据流的形式，然后在到某层（忘了）的时候，它会负责将数据流构造成一个操作系统可以认识的数据结构的形式，这样对操作系统操作会非常方便。
为什么说四元组是连接的唯一标识

我们可能已经多次看到这样一种说法：一个tcp连接由一个连接四元组唯一标识。连接四元组是指<\source ip,source port,target ip,target port>。

为什么需要四元组，我们就不多说了，如果四个元素缺少任何一个都会发生冲突。那在网络接收过程中是如何利用到这四元组呢？
看了上个部分，你可能会有种错觉，是网卡一步一步向上传递的。其实严格说并不是这样，当网卡收到数据之后，首先经过校验没有错误之后，通过DMA直接发送到内存缓冲区中，然后给CPU发送一个中断信号，通知操作系统一个数据包到了。

注意：这里面的内存缓冲区并不是socket的接收缓冲区，而是网卡驱动提前向操作系统申请的一块内存，并且驱动会提前告诉网卡这块内存的地址（注意是物理地址）和大小。如果没有这块内存缓冲区，那么网卡会直接将数据丢掉。
在操作系统获悉到一个数据包来到之后，就利用中断函数来一步步执行并解析数据包，知道TCP层，到了TCP层，TCP要决定将数据包发给那个socket的接收缓冲区。
怎么找？这里TCP就是利用连接四元组，并以这个四元组为key，查找hash表找到对应的socket的socket结构指针，并利用该指针找到对应socket的接收缓冲区，并将载荷数据拷贝进去。
所以，如果想发动攻击，那么直接填写一个对方IP和对方运行服务的端口号，并发送数据，这样是无效的，除了会拥塞网络外，因为没有这样的四元组，所以TCP协议会不知道把载荷数据发给哪个缓冲区。
所以，一种常见的攻击是SYN洪水，它的原理就是，此时服务器会产生大量的socket结构，大量的占据内存，然而并没有ACK数据到达，这样，如果有成千上万个SYN请求，那服务器的内存很快就会耗完，服务器也就down了。
HTTP短连接和长连接

了解了上面的内容之后，才能真正懂得到底什么是短连接和长连接（持久连接）。这里面并没有什么特别复杂的技术。
对于HTTP 1.0的http标准而言，默认连接是短连接，啥叫短连接？就是服务器当发送完最后一个字节的数据之后将关闭连接，也就是回收tcp_sock结构，这样，如果客户端再发送数据给服务器，将直接丢弃。即使此时客户端还有这样的结构，但是我们说连接已经关闭或者已经断了。

那客户端知不知道啥时候服务器的连接关闭？不知道，双方可以在任何时候来关闭自己的连接而没有必要通知对方。不过，对于短连接而言，通知不通知也没有意义了。
那短连接的弊端，大家可能都已经知道了，如果对一个服务器要连续发送多个请求，还需要为每次请求建立新的连接。
为了降低建立连接的时间，HTTP 1.1引入了长连接的概念，并把它搞成了默认的连接方式。啥叫长连接？就是当完成一个业务之后，socket结构并不回收。这样，只要在socket结构还存在的时候，客户端发送的任何数据，服务器都可以收到，这就是所谓的长连接。
相比短连接而言，长连接并没有什么特别的新的技术，只是维护socket结构时间长了。因为，说http长连接更不如说是tcp长连接。
还有一种连接方式是pipeline，或者叫管道化连接。这又是一种啥呢？实际上，管道化连接是一种特殊形式的长连接。我们知道长连接节约了建立连接的时间，但是对于连续N个请求，我们还是需要等前一个响应收到之后才能发送下一个请求，如果在一个timeline上看，有点象一个锯齿。那我们知道网络传输的时间是很长的，那如果我们需要发起N个请求，客户端到服务器的传输时间为t，那总的时间为Nt2；
如何缩短这部分时间呢？有人想到了个很自然的方法，我可不可以不等前一个响应回来就直接发送请求？在timeline图中就像在一个管子里不停的发请求，至于服务器的状态，我也根本不在乎。
管道化连接的方法的确降低了网络传输时间，但是它可能也引入了新的问题。因为客户端并不知道服务器啥时候关闭连接，那有可能管道里的请求，server处理了一部分就关闭了。但是客户端并不知道server处理了哪些？客户端只能选择重新建立连接并重传这些请求。如果这些请求全是对静态数据的请求也就罢了，如果是动态post数据，比如一个订单数据，再不幸的是server已经处理了这个数据，再来一份数据，server将再会处理一遍。这对用户实际的意图讲相差甚远。
也正是这个原因，管道化连接最好不要轻易使用。
再结论

啰里啰嗦说了这么多，基本上是想到哪写到哪，肯定有不详之处，也肯定有不够准确的地方，希望不吝赐教。祝七夕快乐~
转载自：

https://www.cnblogs.com/wreckbear/p/7581721.html

https://blog.csdn.net/zdavb/article/details/47790229

由第一章https://blog.csdn.net/u013978512/article/details/108593972，我们知道了计算机网络分层的概念及由来，这一章我们重点来看下传输层。

传输层主要有TCP协议和UDP协议，我们重点解释TCP 协议的概念。

TCP协议是面向连接的可靠的传输。

什么是链接

那么到底什么叫面向连接呢？

针对什么是连接，我们要首先解释一下什么是套接字。



图中最上面的部分是网络应用程序， 也就是浏览器、 电子邮件客户端、 Web 服务器、 电子邮件服务器等程序， 它们会将收发数据等工作委派给下层的部分来完成。应用程序的下面是 Socket 库， 

而对于在数据收发中扮演关键角色的套接字。在协议栈内部有一块用于存放控制信息的内存空间， 这里记录了用于控制通信操作的控制信息， 例如通信对象的 IP 地址、 端口号、 通信操作的进行状态等。 本来套接字就只是一个概念而已， 并不存在实体， 如果一定要赋予它一个实体， 我们可以说这些控制信息就是套接字的实体， 或者说存放控制信息的内存空间就是套接字的实体。

协议栈在执行操作时需要参阅这些控制信息 。 例如， 在发送数据时需要看一看套接字中的通信对象 IP 地址和端口号， 以便向指定的 IP 地址和端口发送数据。 在发送数据之后， 协议栈需要等待对方返回收到数据的响应信息， 但数据也可能在中途丢失， 永远也等不到对方的响应。 在这样的情况下， 我们不能一直等下去， 需要在等待一定时间之后重新发送丢失的数据， 这就需要协议栈能够知道执行发送数据操作后过了多长时间。 为此， 套接字中必须要记录是否已经收到响应， 以及发送数据后经过了多长时间， 才能根据这些信息按照需要执行重发操作。

      上面说的只是其中一个例子。 套接字中记录了用于控制通信操作的各种控制信息， 协议栈则需要根据这些信息判断下一步的行动， 这就是套接字的作用。TCP连接其实意思就是客户端、服务器双方有创建资源为对方服务，就是连接了。即通信双方交换控制信息， 在套接字中记录这些必要信息并准备数据收发的一连串操作。

下面我们通过命令行的命令看下套接字是的内容

在命令行执行netstat



netstat是在内核中访问网络及相关信息的程序，它能提供TCP连接，TCP和UDP监听，进程内存管理的相关报告。

每一行tcp的信息可以近似认为是一个套接字的内容，local address代表本地ip和端口，foreign address代表目的机的ip和端口，这个可以成为“四元组”。

为什么要三次握手

        进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。


	
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

	
首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
	
	

	
第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

	
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
	
	

	
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
	
     那为什么需要三次握手呢？两次行不行？

     如果两次握手，会有如下场景无法兑付：

     如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

第三次握手失败怎么办？

       当服务器收到 SYN 报文后，服务器会立刻回复 SYN+ACK报文，既确认了客户端的序列号，也把自己的序列号发给了对方。此时，服务器端出现了新连接，状态是 SYN_RCVD。这个状态下，服务器必须建立一个 SYN 半连接队列来维护未完成的握手信息。服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

SYN攻击

        服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

常见的防御 SYN 攻击的方法有如下几种：

缩短超时（SYN Timeout）时间
	
增加最大半连接数
	
过滤网关防护
	
SYN cookies技术
参考：

https://yuanrengu.com/2020/77eef79f.html

 

TCP协议在能够发送数据之前就建立起了“连接”。要实现这个连接，启动TCP连接的那一方首先将发送一个SYN数据包。这只是一个不包含数据的数据包， 然后，打开SYN标记。如果另一方同时在它收到SYN标记的端口通话，它将发回一个SYN+ACK:SYN和ACK标志位都被打开，并将ACK(确认)编 号字段设定为刚收到的那个数据包的顺序号字段的值。接下来，连接发起方为了表示收到了这个SYN+ACK信息，会向发送方发送一个最终的确认信息（ACK 包）。这种SYN、SYN+ACK、ACK的步骤被称为TCP连接建立时的“三次握手”。在这之后，连接就建立起来了。这个连接将一直保持活动状态，直到
 超时或者任何一方发出一个FIN(结束)信号。

任何一方都可以关闭一个TCP连接，要求双方发送一个FIN信号关闭自己的通讯频道。一方可以在另 一方之前关闭，或者双方同时关闭TCP连接。因此，当一方发送一个FIN信号时，另一方可发送“FIN+ACK”，开始关闭自己一方的通信并且确认收到了 第一个FIN信号。发送第一个FIN信号的人接下来再发送一个“FIN+ACK”信息，确认收到第二个FIN信号。另一方就知道这个连接已经关闭了，并且 关闭了自己的连接。发送第一个FIN的人没有办法收到最后一个ACK信号的确认信息。这时它会进入“TIME_WAIT”(等待时间)状态并启动一个定时
 器，防止另一方没有收到ACK信息并且认为连接仍是打开的。一般来说，这个状态会持续1至2分钟。

现在，我们来讨论第一个问题。如果有人(假如一 个黑客)在你的Web服务器上留下一个半开或者半关的连接，那就是一个坏消息。每一个连接都要消耗内存，打开数千个虚假的TCP连接可能导致服务器瘫痪。 当然，你实际上不可能在不影响TCP正常工作的情况下调整TCP定时器。如果你听说过TCP SYN 攻击的话，那就是这个意思。为了防止出现这种情况，大多数操作系统都要限制半开连接的数量。例如，Linux默认的限制一般是256个。
        关于持续 流控制问题，现在我们就来讨论这个问题。TCP中实现它的机制是TCP滑动窗口机制。TCP协议使用“重新发送与正向ACK”来保证数据传输的可靠性。发 送方将等待一段时间，如果没有收到其发送的数据包的ACK确认信息，发送方就要重新发送。顺便说一下，TCP协议中有许多定时器。这只是其中一个定时器。 ACK的概念对于流控制是非常重要的，因为TCP滑动窗口协议使TCP的往复确认变得更有效率。如果TCP要发送一个数据包并且等待每一个ACK确认信 息，它实际上就把数据吞吐量削减了一半。理想的情况是，我们能够一次发送许多数据包，然后等待收到一个确认收到全部数据包的ACK信息，而不用对
 方发来更多的数据。但是，我们如何知道发送了多少个数据包呢?TCP窗口尺寸可以控制在“已发送但是没有确认”的状态下能够容纳多少个数据包。(也就是说,只要自己也就是发送方的窗口足够大,不用管对方是否发送确认ack过来,先提前将数据包放到发送窗口中即可) 如果这个窗 口尺寸很大，我们不必等待ACK信息就可以发送大量的数据包。这实际上就是流控制。

       接收方就是控制窗口大小的那一方。如果接收方将窗口大小设为 “0”，那么，发送方根本就不能发送任何数据。如果这个窗口的尺寸是“1”，那么，我们就回到了简单的“发送和等待ACK”的协议。如果最后的窗口尺寸是 “0”，发送者将发出一个探测信号以搞清这个窗口什么时间再次打开。如果发送方从来没有收到ACK信息，它就一直不断地重试，直到定时器过期。请记住，这 个窗口尺寸在TCP头中是一个16位字段。如果你要一个窗口尺寸(按字节计算)大于16位可以表示的容量（2的16次方个字节），还可以使用一个名为“窗 口缩放”的TCP协议选项。这个选项允许窗口尺寸乘以比例因子。如果没有极大的窗口尺寸，TCP协议就就无法充分利用GB级别的高速连接。这也是我们需要
 针对这些新的高速连接调整TCP参数的原因，

关于TCP流控制的问题，我们不能不提一下Nagle算法。如果我们在一个telnet连接上使用一 个大的TCP窗口会发生什么事情呢?你会输入一个指令（例如敲了一个字母），然后一直等待回应它却迟迟不出现在终端回显上。这对于实时通信来说是一个大问 题。而且，telnet也会增加网络的阻塞度，因为一个字节的数据（例如我们的一次击键）需要40个字节的包头。于是RFC 896定义这个Nagle算法，用以消除小的数据包。这个思路是我们应该在数据发送之前给先把小数据集中起来然后一次性发送，以便提高效率。为了更有效 率，它还限定只允许存在一个未经确认的数据段，你在得到确认信息之前不能发送更多的数据。Telnet和互动SSH连接使用TCP_NODELAY套接口
 选项启用这个功能，这样当你按下一个按键的时候，你能够立即得到一个回应。

当然，我们仍是忽略了有关TCP协议的许多事情。然而，通过这两篇文章的了解，你应该能够理解其它一些更专业的TCP著作。阻塞控制与流控制不同，本文没有讨论。如果你真的对了解TCP协议的全部工作原理感兴趣，你可以详细阅读TCP RFC。

小结

TCP 协议非常善于解决流控制问题，因此非常适应于许多应用程序。TCP协议中的流控制的含义是:“在收到对发送的数据的确认信息这前，我可以发送多少数据?” 这就是TCP窗口。学习阻塞控制的问题可以留作读者的练习。需要指出的是，在TCP协议之下连接速度开始很慢，然后速度逐渐加快。这个做法并不总是最理想 的。

专注分享Linux后台服务器开发，包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等等
我们知道TCP通过一个定时器（timer）采样了RTT并计算RTO，但是，如果网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，然而重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这就导致了恶性循环，最终形成“网络风暴” —— TCP的拥塞控制机制就是用于应对这种情况。 
首先需要了解一个概念，为了在发送端调节所要发送的数据量，定义了一个“拥塞窗口”（Congestion Window），在发送数据时，将拥塞窗口的大小与接收端ack的窗口大小做比较，取较小者作为发送数据量的上限。 
拥塞控制主要是四个算法： 
1.慢启动：意思是刚刚加入网络的连接，一点一点地提速，不要一上来就把路占满。 
连接建好的开始先初始化cwnd = 1，表明可以传一个MSS大小的数据。 
每当收到一个ACK，cwnd++; 呈线性上升 
每当过了一个RTT，cwnd = cwnd*2; 呈指数让升 
阈值ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法” 
2.拥塞避免：当拥塞窗口 cwnd 达到一个阈值时，窗口大小不再呈指数上升，而是以线性上升，避免增长过快导致网络拥塞。 
每当收到一个ACK，cwnd = cwnd + 1/cwnd 
每当过了一个RTT，cwnd = cwnd + 1 
拥塞发生：当发生丢包进行数据包重传时，表示网络已经拥塞。分两种情况进行处理： 
等到RTO超时，重传数据包 
sshthresh = cwnd /2 
cwnd 重置为 1 
3.进入慢启动过程 
在收到3个duplicate ACK时就开启重传，而不用等到RTO超时 
sshthresh = cwnd = cwnd /2 
进入快速恢复算法——Fast Recovery 
4.快速恢复：至少收到了3个Duplicated Acks，说明网络也不那么糟糕，可以快速恢复。 
cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了） 
重传Duplicated ACKs指定的数据包 
如果再收到 duplicated Acks，那么cwnd = cwnd +1 
如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。
关注我，每天分享Linux后台服务器开发，包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等