我们在平时的开发过程中,或多或少都会涉猎到网络传输这块。
这篇文章,主要是整理一下 TCP 的一些知识要点,作为一名开发者来说,尽管有那么多的基础设施(框架、组件)帮我们屏蔽了这些细节。当我仍然认为了解它的一些基本原理必有些裨益,尤其是当你在分布式环境上遇到一些棘手问题时,一些原理性的知识可能会让你快速找到答案。
TCP 是传输层的协议,全称是叫做 Transmission Control Protocol,这个协议在 IETF RFC 793 进行了定义。
在互联网产生之前,我们的电脑都是相互独立的,每台机器都有着自己的操作系统并保持着自己的运行。
于是,为了将这些电脑连接起来,并能够基于一种“通道”的形式进行数据、资源的传输及交互,IETF 制定了 TCP 协议。
那么,IETF又是什么? 这是一个令人尊敬的技术组织,叫 Internet Engineering Task Force,即互联网工程任务组。
这是一个成立于1985年的开放性组织,现在我们所提到的 HTTP、TCP、IP 这些重要的网络协议,都是出自于该组织。
可以这么说,IETF 是互联网的始作俑者,没有它就没有现在繁荣的互联网了。
值得一提的是,IETF并非权贵组织,它是一个“来自民间” 的自组织、自管理的团队,非常崇尚于自由平等的精神。
整个互联网的底层机制是由一套标准网络协议组成的,为了更方便于理解,人们便定义了所谓的“网络分层模型”。
在学习计算机网络课程的时候,都会提到两种网络模型,如下:
在以前,由于术语众多,有许多人经常被OSI、ISO所迷惑..
从上面的图中可以看出,TCP/IP 基本上是OSI 模型的简化版,当然也更加容易理解。
在网络层以下,物理层、数据链路层所涉及的一些技术手段及概念都相对晦涩难懂,就比如光缆、中继器、交换机等需要一些专业背景才能掌握通透。
对于大多数的软件应用来说,将网络层以下的部分统称为“网络接口层” 无疑是更加简单的。
因此,OSI 模型尽管非常完善且全面,但已经被 TCP/IP 模型所淘汰,在互联网应用盛行的今天很少被提及。
图-TCP/IP 网络模型
TCP 是整个 TCP/IP 协议族中最重要的传输层协议,它定义了一种面向连接的、可靠的、基于流的传输方式。
HTTP 是基于 TCP 的,所以说 TCP 是整个互联网的协议其一并不为过。
同时,我们在使用 HTTP 协议实现应用系统间的交互时,也经常免不了会与 TCP 打上交道。因此有必要了解一些基本机制。
首先,TCP 是基于连接的,也就是在进行数据传输之前,客户端与服务端(或者说是通信的双方)需要先建立一个可信的连接。
在数据传输结束后,再通过一种协定的方式断开连接,由通信的双方释放资源。这里涉及到的,就是常说的“三次握手”、”四次挥手”
其次,TCP 是可靠的,它定义了一种数据包的”超时重传机制”,简单说,就是每一个数据包在发送出去后的都会等待一个响应。
如果指定时间内没有收到响应,由发送方进行一定次数的重传来保证数据的可靠传输。
最后,TCP 是基于流的,这是指在传输数据时应用层不需要关注数据包的边界,TCP在数据传输时会自动根据网络环境将数据进行缓冲、分组、合并。
这点跟基于报文的协议(UDP)是截然不同的。当然,基于流的传输也保证了数据收发的有序性,因此每个数据包都附带上一个属于当前连接的序列号。
全双工是通讯上的术语,一般在软件开发领域提到的并不多。
这是指数据同时在两个方向上传输,TCP 是基于全双工的可信传输协议。
当然 UDP 也可以实现全双工的传输,但 TCP 只能实现点对点的传输,无法支持广播或者多播(分组)。
黑板:半双工的区别在于,同一时间只能有一个方向的传输
透视一个协议的最原始的方法就是看它的数据包,一个TCP 的报文格式如下:
这里面的字段就包括了:
源端口
表明发送端所使用的端口号,用于目标主机回应。
目的端口
表明要连接的目标主机的端口号。
序号
表明发送的数据包的顺序,一般为上次发送包中的顺序号+1。
若该数据包是整个TCP连接中的第一个包(SYN包),则该值是随机生成的。
确认号
表明本端TCP已经接收到的数据,其值表示期待对端发送的下一个字节的序号。
实际上告诉对方,在这个序号减1以前的字节已正确接收。
若该数据包是整个TCP连接中的第一个包(SYN包),则确认号一般为0。
数据偏移
表示以32位(4字节)为单位的TCP分组头的总长度(首部长度),用于确定用户数据区的起始位置。
在没有可变内容的情况下,TCP头部的大小为20字节,对应该值为5。
标志位
紧急标志位(URG):开启时表明此数据包处于紧急状态应该优先处理
确认标志位(ACK):开启时表明确认号有效,否则忽略确认号
推送标志位(PSH):开启时表明应该尽快交付给应用进程,而不必等到缓存区填满才推送,比如 telnet 的场景
复位标志位(RST):开启时表明TCP连接出现连接出现错误,数据包非法拒绝连接
同步标志位(SYN):开启时表明连接建立的标志
终止标志位(FIN):开启时表明释放一个连接
窗口大小
表明期望接受到的数据包字节数,用于拥塞控制。
校验和
实现对TCP报文头以及数据区进行校验。
紧急指针
在紧急状态下(URG打开),指出窗口中紧急数据的位置(末端)。
选项(可变)
用于支持一些特殊的变量,比如最大分组长度(MSS)。
填充
用于保证可变选项为32 bit的整数倍。
黑板:一般情况下TCP 头部为20字节,加上20字节的 IP头部,一个数据包至少包含40字节的头部
链是指链路,这个是物理层的概念,比如光缆光纤,或是无线的电磁波。
但这里所说的链路其实是网络连接的意思,即IP 上层的概念。
那么,一个TCP 正常的通讯流程,会包含建链(建立连接)、传输数据、拆链(关闭连接),如下图所示:
(图来自网络)
据上图所示,在进行 TCP 进行数据传输时,都不可避免的会经过这两个阶段:
下面,重点说明下建链与拆链的过程
在建立TCP连接时,需要经过三次交互,也成为三次握手(HandShake)。
1、客户端发起连接请求,发送 SYN包(SYN=i)到服务器,并进入到SYN-SEND状态,等待服务器确认
2、服务器收到SYN包后,必须确认客户的 SYN(ack=i+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器进入SYN-RECV状态
3、客户端收到服务器的SYN+ACK包,向服务器发送确认报ACK(ack=k+1),此后客户端和服务器进入ESTABLISHED状态,双方可以开始传送数据。
在谈论三次握手的时候,有几个问题是需要关注的:
问题1. 为什么是三次握手
这个问题在技术面试时屡试不爽,原话是能不能两次,或者是四次握手呢?
答案就是,TCP 是可靠的传输,在建立连接时就应该经过两端的确认过程,如上面的流程,
只有在三次握手的情况下,客户端和服务端都经过了一次真正(SYN+ACK)的确认过程。这样的连接便认为是可信的。
此外,如果仅仅只是两次握手,一旦网络不稳定造成 SYN 包重传则会直接导致重复建立连接,浪费资源。
问题2. 什么是syn flood攻击
syn flood 是一种经典的 ddos攻击手段,这里面用到了TCP 三次握手存在的漏洞。
在上面的图中,可以看到当服务端接收到 SYN 后进入 SYN-RECV 状态,此时的连接称为半连接,同时会被服务端写入一个 半连接队列。
想象一下,如果攻击者在短时间内不断的向服务端发送大量的 SYN 包而不响应,那么服务器的 半连接队列很快会被写满,从而导致无法工作。
实现 syn flood 的手段,可以通过伪造源 IP 的方式,这样服务器的响应就永远到达不了客户端(握手无法完成);
当然,通过设定客户端防火墙规则也可以达到同样的目的。
对 syn flood 实现拦截是比较困难的,可以通过启用 syn_cookies 的方式实现缓解,但这通常不是最佳方案。
最好的办法是通过专业的防火墙来解决,基本上所有的云计算大T 都具备这个能力。
关于 syn flood 可以看看这篇文章
问题3. 半连接队列和全连接队列如何调优
这里提到了一个”半连接队列”(syns queue),与其对应的还有一个 “全连接队列”(accept queue)
前者用于暂存未建立完全的连接,后者是连接在成功建立后进入的一个队列。
半连接队列默认大小可以通过内核参数调整:
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
黑板:tcp_max_syn_backlog 在 syn_cookies 开启时是无效的,这两个选项存在冲突
对于全连接队列,如果服务器未能及时通过 accept 调用将其中的连接取走,会导致队列溢出(连接失效)
全连接队列的大小的内核调优方式:
echo 4096 > /proc/sys/net/core/somaxconn
那么,是不是只有内核调优这种方法能影响这两个参数呢?答案是否定的。
实际上,在应用层调用 socket listen 时也支持设置一个 backlog参数,这几个之间的关系如下:
半连接队列长度 = min(backlog,内核 net.core.somaxconn,内核 tcp_max_syn_backlog)
全连接队列长度 = min(backlog,内核 net.core.somaxconn)
黑板:一般的应用服务器如 netty、tomcat 都支持设置 backlog 参数,但是在真正进行调优时还需要配合考虑内核参数的配置。
在释放连接时,由于TCP是全双工的,因此最后要由两端分别进行关闭,这个流程如下:
1、客户端发送一个FIN,用来关闭客户端到服务器的数据传送,客户端进入FIN_WAIT_1状态。
2、服务器收到FIN后,发送一个ACK给客户端,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),服务器进入CLOSE_WAIT状态,而客户端进入FIN_WAIT2状态。
3、服务器发送一个FIN,用来关闭服务器到客户端的数据传送,服务器进入LAST_ACK状态。
4、客户端收到FIN后,客户端进入TIME_WAIT状态,接着发送一个ACK给服务器,确认序号为收到序号+1,服务器进入CLOSED状态,完成释放。
关闭连接有主动关闭和被动关闭一说,这里为了简化理解,我们以客户端作为主动关闭方,服务器为被动关闭方。
四次挥手需要关注的问题:
问题1. 为什么是四次挥手
发送FIN的一方就是主动关闭(客户端),而另一方则为被动关闭(服务器)。
当一方发送了FIN,则表示在这一方不再会有数据的发送。
其中当被动关闭方受到对方的FIN时,此时往往可能还有数据需要发送过去,因此无法立即发送FIN(也就是无法将FIN与ACK合并发送),
而是在等待自己的数据发送完毕后再单独发送FIN,因此整个过程需要四次交互。
问题2. 什么是半关闭
客户端在收到第一个FIN的ACK响应后,会进入FIN_WAIT2 状态时,此时服务器处于 CLOSE_WAIT状态,这种状态就称之为半关闭。
从半关闭到全关闭,需要等待第二次FIN的确认才算结束。此时,客户端要等到服务器的FIN才能进入TIME_WAIT,
如果对方迟迟不发送FIN呢,则会等待一段时间后超时,这个可以通过内核参数tcp_fin_timeout控制,默认是60s。
问题3. 为什么服务器会有大量 closewait
半关闭的状态下的服务器连接会处于 closewait 状态,直到服务器发送了FIN。
那么在应用层则是调用socket.close()会执行FIN的发送,如果服务器出现大量CLOSE_WAIT状态的连接,那么有可能的原因:
问题4. timewait 会带来什么问题
当客户端收到了对方的FIN时,会进入TIMEWAIT状态,此时会保持一段时间再进入CLOSE状态。
这么做的原因主要还是为了可靠的关闭连接。在将TCP 进行可靠性设计之时就考虑了许多网络的不稳定性的因素,比如:
**发送给对方的ACK 可能会无法及时收到,此时对方可能重传FIN过来,如果提前进入CLOSE则会返回RST而不是ACK,就会影响关闭流程。_**
因此 TIME_WAIT 状态默认会持续一段时间,直到确认不会再有重传的数据包之后再安全的关闭。
黑板:这里timewait的持续时间默认是 2MSL(总共1分钟),这个MSL叫*Max Segment Lifetime,也就是关于一个数据包在网络中传输的最大生命周期的预设。
MSL默认是30s,当然这个值在现在已经可以大幅度缩减。可见在当时在设计之初,网络状况有多么的糟糕。
那么timewait会带来什么问题?
如果频繁的主动关闭连接,可能会产生大量 timewait,由于timewait 的连接占用了一个句柄及少量内存(4K),那么就有可能会影响其他连接的建立,比如:
出现 too many open files 异常..
该如何解决:
黑板:HTTP 协议里头发现了timewait的问题,于是在 HTTP 1.1 中定义了 KeepAlive 用来支持连接的重用。
问题5. RST 是什么,为什么会出现
RST 是一个特殊的标记,用来表示当前应该立即终止连接。以下这些情况都会产生RST:
RST 机制有时候也会被利用,做一些端口的扫描,如下:
-> 端口开启,可接受SYN
-> 端口关闭,响应RST
原文只是想总结下 TCP 参数调优的几个细节,没想到TCP 牵扯出来的东西实在太多,光是一个简单的握手、挥手流程就存在这么多的细节和坑。
可以说为了保证数据传输的可靠性,早期的设计者确实考虑了太多的东西。当然,这也为上层的应用实现铺平了道路。
鉴于篇幅原因,只做了TCP 建链、拆链方面的介绍。关于数据的传输的一些细节,将在下篇文章梳理及分享。
VM57973 sockjs.min.js:2 Uncaught Error: Incompatible SockJS! Main site uses: "1.4.0", the iframe: "1.5.0".
Chrome 51 开始,浏览器的 Cookie 新增加了一个`SameSite`属性,用来防止 CSRF 攻击和用户追踪。
本文首先会简单介绍下前端的常见缓存方式,再引入serviceworker的概念,针对其原理和如何运用进行介绍。然后基于google推出的第三方库workbox,在产品中进行运用实践,并对其原理进行简要剖析。
缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少带宽,降低网络负荷。 对于一个数据请求来说,可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求,或者发起了请求但后端存储的数据和前端一致,那么就没有必要再将数据回传回来,这样就减少了响应数据。
TCP在连接过程的三次握手完成后,开始传数据,并不是一开始向网络通道中发送大量的数据包,这样很容易导致网络中路由器缓存空间耗尽,从而发生拥塞;而是根据初始的cwnd大小逐步增加发送的数据量,cwnd初始化为1个最大报文段(MSS)大小(**这个值可配置不一定是1个MSS**);每当有一个报文段被确认,cwnd大小指数增长。
我们在平时的开发过程中,或多或少都会涉猎到网络传输这块。 这篇文章,主要是整理一下 TCP 的一些知识要点,作为一名开发者来说,尽管有那么多的基础设施(框架、组件)帮我们屏蔽了这些细节。当我仍然认为了解它的一些基本原理必有些裨益,尤其是当你在分布式环境上遇到一些棘手问题时,一些原理性的知识可能会让你快速找到答案。
WebP,或非正式发音为 weppy ,是 Google开发者大约5年前推出的 一种图像格式 。
感谢Google巢鹏的提供的内容分享。Life of a Pixel这个演讲一开始是Chrome组新人入职的学习资料,给新人一个从高层次去看Chromium如何从HTML / CSS / JS 显示到屏幕的网页。这个演讲一直在更新,所以大家可以通过看这个演讲更新自己对Chromium的理解。
本地测试时,简易忽略chrome浏览器的证书问题
http请求的完整过程
IE6/7浏览器兼容querySelectorAll、 querySelector
preload作为一个新的web标准,旨在提高性能和为web开发人员提供更细粒度的加载控制。Preload使开发者能够自定义资源的加载逻辑,且无需忍受基于脚本的资源加载器带来的性能损失。
网站前后端性能优化的34条经验方法
CSRF(Cross-site request forgery跨站请求伪造,也被称成为“one click attack”或者session riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相 左。XSS利用站点内的信任用户,而XSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,XSRF攻击往往不大流行(因此对其 进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性
http常用状态码