wireshark中的SYN分组和SYNACK分组是什么?

计算往返时间应该就是从发出数据段到收到对该数据段的ACK。程序里面记录时间就可以了。如果是网络截包winpcap的，截包里面包含了时间，在统计菜单也有RTT的分析。
第一次
第一次握手：建立连接时
三次握手
，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：

Transmission Control Protocol，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议

TCP协议的目的是： 在不可靠传输的IP层之上建立一套可靠传输的机制。 TCP的可靠只是对于它自身来说的, 甚至是对于socket接口层, 两个系统就不是可靠的了, 因为发送出去的数据, 没有确保对方真正的读到（所以要在业务层做重传和确认机制）。

可靠传输的第一要素是 确认 , 第二要素是 重传 , 第三要素是 顺序 。 任何一个可靠传输的系统, 都必须包含这三个要素。 数据校验 也是必要的。

传输是一个广义的概念, 不局限于狭义的网络传输, 应该理解为通信和交互 任何涉及到通信和交互的东西, 都可以借鉴TCP的思想。无论是在UDP上实现可靠传输或者创建自己的通信系统，无论这个系统是以API方式还是服务方式，只要是一个通信系统，就要考虑这三个要素。

SeqNum的增加是和传输的字节数相关的。 上图中，三次握手后，来了两个Len:1440的包，而第二个包的SeqNum就成了1441。然后第一个ACK回的是1441（下一个待接收的字节号），表示第一个1440收到了。

网络上的传输是没有连接的，包括TCP也是一样的 。而TCP所谓的“连接”，其实只不过是在通讯的双方维护一个“连接状态”，让它看上去好像有连接一样。所以，TCP的状态变换是非常重要的。

查看各种状态的数量
ss -ant | awk '{++s[$1]} END {for(k in s) print k,s[k]}'

通过三次握手完成连接的建立

三次握手的目的是交换通信双方的初始化序号，以保证应用层接收到的数据不会乱序，所以叫SYN(Synchronize Sequence Numbers)。

ISN是不能hard code的，不然会出问题的。比如：如果连接建好后始终用1来做ISN，如果client发了30个segment过去，但是网络断了，于是client重连，又用了1做ISN，但是之前连接的那些包到了，于是就被当成了新连接的包，此时，client的Sequence Number可能是3，而Server端认为client端的这个号是30了。全乱了。RFC793中说，ISN会和一个假的时钟绑在一起，这个时钟会在每4微秒对ISN做加一 *** 作，直到超过232，又从0开始。这样，一个ISN的周期大约是455个小时。因为，我们假设我们的TCP Segment在网络上的存活时间不会超过Maximum Segment Lifetime（MSL），所以，只要MSL的值小于455小时，那么，我们就不会重用到ISN。

如果Server端接到了Clien发的SYN后回了SYN-ACK，之后Client掉线了，Server端没有收到Client返回的ACK，那么，这个连接就处于一个中间状态，即没成功，也没失败。于是，Server端如果在一定时间内没有收到的ACK会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻番，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 26 -1 = 63s，TCP才会断开这个连接。

客户端给服务器发了一个SYN后，就下线了，于是服务器需要默认等63s才会断开连接，这样，攻击者就可以把服务器的SYN连接的队列耗尽，让正常的连接请求不能处理。
于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事：当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie），此时服务器并没有保留客户端的SYN包。如果是攻击者则不会有响应，如果是正常连接，则会把这个SYN Cookie发回来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。
千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为sync cookies是妥协版的TCP协议，并不严谨。应该调整三个TCP参数：tcp_synack_retries减少重试次数，tcp_max_syn_backlog增大SYN连接数，tcp_abort_on_overflow处理不过来干脆就直接拒绝连接

因为TCP是全双工的，因此断开连接需要4次挥手，发送方和接收方都需要发送Fin和Ack。如果两边同时断连接，那就会就进入到CLOSING状态，然后到达TIME_WAIT状态。

指的是报文段的最大生存时间，如果报文段在网络中活动了MSL时间，还没有被接收，那么会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是两分钟，不过实际上不同的 *** 作系统可能有不同的设置，以Linux为例，通常是半分钟，两倍的MSL就是一分钟，也就是60秒

主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留两倍的MSL时长。由于TIME_WAIT的存在，大量短连接会占有大量的端口，造成无法新建连接。

主动关闭的一方发出 FIN包，被动关闭的一方响应ACK包，此时，被动关闭的一方就进入了CLOSE_WAIT状态。如果一切正常，稍后被动关闭的一方也会发出FIN包，然后迁移到LAST_ACK状态。

CLOSE_WAIT状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT状态，那么就意味着被动关闭的一方没有及时发出FIN包。

TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。

接收端给发送端的Ack确认只会确认最后一个连续的包 ，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注意此时3没收到），此时的TCP会怎么办？我们要知道，因为正如前面所说的，SeqNum和Ack是以字节数为单位，所以ack的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了

但总体来说都不好。因为都在等timeout，timeout可能会很长

不以时间驱动，而以数据驱动重传
如果包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传

Selective Acknowledgment, 需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版，在发送端就可以根据回传的SACK来知道哪些数据到了，哪些没有收到

重复收到数据的问题，使用了SACK来告诉发送方有哪些数据被重复接收了

经典算法：Karn/Partridge算法，Jacobson/Karels算法

TCP必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包

Advertised-Window ：接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来

接收端LastByteRead指向了TCP缓冲区中读到的位置，NextByteExpected指向的地方是收到的连续包的最后一个位置，LastByteRcved指向的是收到的包的最后一个位置，我们可以看到中间有些数据还没有到达，所以有数据空白区。

发送端的LastByteAcked指向了被接收端Ack过的位置（表示成功发送确认），LastByteSent表示发出去了，但还没有收到成功确认的Ack，LastByteWritten指向的是上层应用正在写的地方。

接收端在给发送端回ACK中会汇报自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;

收到36的ack，并发出了46-51的字节

如果Window变成0了，发送端就不发数据了

如果发送端不发数据了，接收方一会儿Window size 可用了，怎么通知发送端呢：TCP使用了Zero Window Probe技术，缩写为ZWP，也就是说，发送端在窗口变成0后，会发ZWP的包给接收方，让接收方来ack他的Window尺寸，一般这个值会设置成3次，每次大约30-60秒。如果3次过后还是0的话，有的TCP实现就会发RST把链接断了。

如果你的网络包可以塞满MTU，那么你可以用满整个带宽，如果不能，那么你就会浪费带宽。避免对小的window size做出响应，直到有足够大的window size再响应。

如果这个问题是由Receiver端引起的，那么就会使用David D Clark’s 方案。在receiver端，如果收到的数据导致window size小于某个值，可以直接ack(0)回sender，这样就把window给关闭了，也阻止了sender再发数据过来，等到receiver端处理了一些数据后windows size大于等于了MSS，或者receiver buffer有一半为空，就可以把window打开让send 发送数据过来。

如果这个问题是由Sender端引起的，那么就会使用著名的 Nagle’s algorithm。这个算法的思路也是延时处理，他有两个主要的条件：1）要等到 Window Size >= MSS 或是 Data Size >= MSS，2）等待时间或是超时200ms，这两个条件有一个满足，他才会发数据，否则就是在攒数据。

TCP_CORK是禁止小包发送，而Nagle算法没有禁止小包发送，只是禁止了大量的小包发送

TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲

拥塞控制的论文请参看 《Congestion Avoidance and Control》

主要算法有：慢启动，拥塞避免，拥塞发生，快速恢复，TCP New Reno，FACK算法，TCP Vegas拥塞控制算法

TCP网络协议及其思想的应用
TCP 的那些事儿（上）
TCP 的那些事儿（下）
tcp为什么是三次握手，为什么不是两次或四次？
记一次TIME_WAIT网络故障
再叙TIME_WAIT
tcp_tw_recycle和tcp_timestamps导致connect失败问题
tcp短连接TIME_WAIT问题解决方法大全（1）- 高屋建瓴
tcp短连接TIME_WAIT问题解决方法大全（2）- SO_LINGER
tcp短连接TIME_WAIT问题解决方法大全（3）- tcp_tw_recycle
tcp短连接TIME_WAIT问题解决方法大全（4）- tcp_tw_reuse
tcp短连接TIME_WAIT问题解决方法大全（5）- tcp_max_tw_buckets
TCP的TIME_WAIT快速回收与重用
浅谈CLOSE_WAIT
又见CLOSE_WAIT
PHP升级导致系统负载过高问题分析
Coping with the TCP TIME-WAIT state on busy Linux servers

TCP三次握手是在TCP / IP网络中用于在服务器和客户端之间建立连接的过程。这是一个三步过程，需要客户端和服务器在真实数据通信过程开始之前交换同步和确认数据包。

三次握手过程的设计方式是，两端都可以帮助您同时启动，协商和分离TCP套接字连接。它允许您同时在两个方向上传输多个TCP套接字连接。

TCP通信以三次握手开始。在此TCP握手过程中，客户端需要通过请求与服务器的通信会话来发起会话：

</center>

这是三次握手过程的一个简单示例，包括三个步骤：

数据传输过程结束后，TCP自动终止两个单独端点之间的连接。

What Is TCP Three-Way HandShake

Denial of Service，简称DoS，造成DoS攻击的行为被称为DoS攻击，其目的是使计算机或网络无法提供正常的服务。

常见的DoS攻击有计算机网络 带宽攻击 和 连通性攻击 。

带宽攻击 指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。</br>
连通性攻击 指用大量的连接请求冲击计算机，使得所有可用的 *** 作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求。

常用攻击手段有：SYN Flood、WinNuke、死亡之Ping、ICMP/SMURF、Finger炸d、Land攻击、Ping洪流、Rwhod、Teardrop、TARGA3、UDP攻击等。

书中以SYN Flood攻击为例，详细介绍这种典型的DoS攻击：

SYN Flood是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，使被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。

SYNFlood攻击利用了TCP协议中的三次握手（Three-way Handshake）

SYN Flood攻击的具体原理：</br>
TCP连接的三次握手中，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成）。

这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接。这段时间的长度称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30s～2min）；</br>
一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况（伪造IP地址），服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源。

即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。</br>
如果服务器的TCP/IP栈不够大，最后的结果往往是堆栈溢出崩溃——即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬正常客户的请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况就称作：服务器端受到了SYN Flood攻击（SYN洪水攻击）

拒绝服务攻击主要是利用了系统的一些漏洞。漏洞利用拒绝服务攻击是一种利用漏洞造成软件不能正常运行的攻击方式。这种拒绝服务不依赖大量傀儡机，也不需要发送大量访问请求，而仅仅是利用目标节点软件的安全漏洞，通过精心构造恶意数据包，造成目标节点软件不能有效运行。

分布式拒绝服务（DDoS：Distributed Denial of Service）攻击是一种资源耗尽型攻击，通常也被称作洪水攻击。</br>
利用分布于网络上的大量节点向同一目标节点发起的引起目标节点资源被大量消耗而不能正常对外提供服务的网络攻击方式。

分布式拒绝服务攻击主要是指那些借助外界的平台，如客户或者是服务器本身，把不同的计算机系统联合在一起，对其进行攻击，进而加倍地增强拒绝攻击的成果。一般情况，攻击者将分布式拒绝服务攻击的主控程序安装在一个用于控制的计算机上，将受控程序安装部署在因特网的多台计算机上。主控程序可以与受控程序进行通信并控制受控程序的行为，当主控程序发送特定的指令时，受控程序即可根据指令发动攻击。

DDoS攻击通过大量合法的请求占用大量网络资源，以达到瘫痪网络的目的。这种攻击方式有以下几种：

分布式拒绝服务攻击的步骤如下：</br>
第1步：攻击者使用扫描工具扫描大量主机以寻找潜在入侵目标；</br>
第2步：黑客设法入侵有安全漏洞的主机并获取控制权。这些主机将被用于放置后门、守护程序甚至是客户程序；</br>
第3步：黑客在得到入侵计算机清单后，从中选出满足建立网络所需要的主机，放置已编译好的守护程序，并对被控制的计算机发送命令；</br>
第4步：黑客发送控制命令给主机，准备启动对目标系统的攻击；
第5步：主机发送攻击信号给被控制计算机开始对目标系统发起攻击；
第6步：目标系统被无数伪造的请求所淹没，从而无法对合法用户进行响应，DDoS攻击成功。

DDoS攻击的效果是非常明显的，由于整个过程是自动化的，攻击者能够在5s钟内入侵一台主机并安装攻击工具。也就是说，在短短的一小时内可以入侵数千台主机，并使某一台主机可能要遭受1000MB/s数据量的攻击，这一数据量相当于104亿人同时拨打某公司的一部电话号码。

分布式反射拒绝服务攻击（DRDoS：Distributed Reflection Denial of Service）是一种较新的资源耗尽型拒绝服务攻击。

与分布式拒绝服务攻击使用伪造源IP地址不同，分布式反射拒绝服务攻击的来源IP地址全是真实地址，这些真实的网络节点本身并没有安全漏洞，而是利用TCP三次握手来实现的。

首先，攻击者通过控制的傀儡机使用受害者IP地址作为源地址向任意处于活动状态的网络节点（如核心路由器、域名服务器、大型网站等）发送带有SYN标记的数据包，也就是TCP三次握手的第一步；</br>
处于活动状态的网络节点接收到伪造源IP地址的数据包后，将会按照协议要求向受害者进行应答，发送带有SYN、ACK标记的应答数据包。当攻击者使用大量傀儡机同时发起攻击时，即完成了一次分布式反射拒绝服务攻击。

分布式反射拒绝服务攻击最典型的攻击是Smurf攻击：</br>

第一步：攻击者向被利用网络A的 广播地址 发送一个ICMP协议的“echo”请求数据报，该数据报源地址被伪造成1025489。</br>
第二步：网络A上的所有主机都向该伪造的源地址返回一个“echo”响应，造成该主机服务中断。</br>

现在的拒绝服务攻击很多都是利用工具自动化完成的。</br>
攻击者控制某些主机不停地发送大量数据包给某服务器，造成服务器资源耗尽，一直到主机崩溃。CC主要是用来消耗服务器资源的。每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，模拟多个用户（多少线程就是多少用户）不停地访问那些需要大量数据 *** 作（就是需要大量CPU时间）的页面，造成服务器资源的浪费，CPU负荷长时间处于100%，永远都有处理不完的连接，直至网络拥塞，正常的访问被中止。

拒绝服务攻击通常是很难防范的，不过也有一些防护措施：</br>
1加强用户的安全防范意识，关闭不必要的网络接口，降低因个人疏忽造成的不安全因素，安装防范功能较强的软件，对计算机做定时的安全扫描工作；</br>
2增加安全防范手段，了解和掌握可以有效地防治安全漏洞的软件，使用一些专门的漏洞检查工具进行问题的检测，如网络测试仪、流量测试仪等，及时地找出修复漏洞的方法和措施，减少不必要的损失。</br>
3正确运用安全防范工具，及时地使用网络检测软件对不安全因素进行检测，使用那些专门检测网络安全隐患的软件，定期进行检测。</br>

TCP是属于网络分层中的传输层，因为OSI分为7层，感觉太麻烦了，所以分为四层就好了，简单。
分层以及每层的协议，TCP是属于传输层，如下两张图：
TCP三次握手会涉及到状态转换所以这里贴出TCP的状态转换图如下：
TCP三次握手简述
TCP三次握手如图：
第一次握手
客户主动（active open）去connect服务器，并且发送SYN 假设序列号为J,
服务器是被动打开(passive open)
第二次握手
服务器在收到SYN后，它会发送一个SYN以及一个ACK（应答）给客户，
ACK的序列号是 J+1表示是给SYN J的应答，新发送的SYN K 序列号是K
第三次握手
客户在收到新SYN K, ACK J+1 后，也回应ACK K+1 以表示收到了，
然后两边就可以开始数据发送数据了
使用tcpdump观察如下：因为都是在本机同时运行client和server所以命令为：tcpdump -i lo port 5555, 只能监听回路lo接口，结果如下
如图用红色圈起来的就是3次握手，但是为什么最后一次握手，为什么ack = 1,而不是369535922 呢，
这是因为这里的第三次握手tcpdump显示的是相对的顺序号。但是为了便于观察我们需要把tcpdump的
顺序号变为绝对的顺序号。
命令只需要加-S(大写)便可，即：tcpdump -i lo port 5555 -S
加上之后结果就正常了如下图：
从tcpdump的数据，可以明显的看到三次握手的过程是：
第一次握手：client syn 2322326583 —> server
第二次握手：server syn 3573692787, ack 2322326583 + 1 —> client
第三次握手：client ack 3573692787 + 1 -->server
TCP三次握手详细解析过程：
第一次握手
客户在socket() connect()后主动(active open)连接上服务器, 发送SYN ，这时客户端的状态是SYN_SENT
服务器在进行socket(),bind(),listen()后等待客户的连接，收到客户端的 SYN 后，
1半连接队列(syn queue)未满
服务器将该连接的状态变为SYN_RCVD, 服务器把连接信息放到半连接队列(syn queue)里面。
2半连接队列(syn queue)已满
服务器不会将该连接的状态变为SYN_RCVD，且将该连接丢弃(SYN flood攻击就是利用这个原理，
对于SYN foold攻击，应对方法之一是使syncookies生效，将其值置1即可，路径/proc/sys/net/ipv4/tcp_syncookies，
即使是半连接队列syn queue已经满了，也可以接收正常的非恶意攻击的客户端的请求，
但是这种方法只在无计可施的情况下使用，man tcp里面的解析是这样说的，
但是我不知道为什么Centos69默认是置为1，所以这让我很疑惑
)。
半连接队列(syn queue)最大值 /proc/sys/net/ipv4/tcp_max_syn_backlog
SYN flood攻击
攻击方的客户端只发送SYN分节给服务器，然后对服务器发回来的SYN+ACK什么也不做，直接忽略掉，
不发送ACK给服务器；这样就可以占据着服务器的半连接队列的资源，导致正常的客户端连接无法连接上服务器。-----[维基百科]
(SYN flood攻击的方式其实也分两种，第一种，攻击方的客户端一直发送SYN，对于服务器回应的SYN+ACK什么也不做，不回应ACK, 第二种，攻击方的客户端发送SYN时，将源IP改为一个虚假的IP, 然后服务器将SYN+ACK发送到虚假的IP, 这样当然永远也得不到ACK的回应。)
第二次握手
服务器返回SYN+ACK给到客户端，客户端收到SYN+ACK后，状态从SYN_SENT变为ESTABLISHED，
也即是connect()函数的返回。
第三次握手
全连接队列(accept queue)的最大值 /proc/sys/net/core/somaxconn (默认128)
全连接队列值 = min(backlog, somaxconn)
这里的backlog是listen(int sockfd, int backlog)函数里面的那个参数backlog
1全连接队列(accept queue)未满
服务器收到客户端发来的ACK, 服务端该连接的状态从SYN_RCVD变为ESTABLISHED,
然后服务器将该连接从半连接队列(syn queue)里面移除，且将该连接的信息放到全连接队列(accept queue)里面。
2全连接队列(accept queue)已满
服务器收到客户端发来的ACK, 不会将该连接的状态从SYN_RCVD变为ESTABLISHED。
当然全连接队列(accept queue)已满时，则根据 tcp_abort_on_overflow 的值来执行相应动作
/proc/sys/net/ipv4/tcp_abort_on_overflow 查看参数值
21 tcp_abort_on_overflow = 0
则服务器建立该连接的定时器，
这个定时器是一个服务器的规则是从新发送syn+ack的时间间隔成倍的增加，
比如从新了第二次握手，进行了5次，这五次的时间分别是 1s, 2s,4s,8s,16s,
这种倍数规则叫“二进制指数退让”(binary exponential backoff)
给客户端定时从新发回SYN+ACK即从新进行第二次握手，(如果客户端设定的超时时间比较短就很容易出现异常)
服务器从新进行第二次握手的次数/proc/sys/net/ipv4/tcp_synack_retries
22 tcp_abort_on_overflow = 1
关于tcp_abort_on_overflow的解析如下：
意思应该是，当 tcp_abort_on_overflow 等于1 时,重置连接(一般是发送RST给客户端)，
至于怎么重置连接是系统的事情了。
不过我在查资料的过程发现，阿里中间件团队博客说并不是发送RST， —[阿里中间件团队博客]
这个博客跑的实例观察到的是服务器会忽略client传过来的包，然后client重传，一定次数后client认为异常，然后断开连接。
当然，我们写代码的都知道代码是第一手的注释，实践是检验真理的唯一标准，
最好还是自己以自己实践为准，因为可能你的环境跟别人的不一样。)
查看全连接队列(accept queue)的使用情况
如上图，第二列Recv-Q是，全连接队列接收到达的连接，第三列是Send-Q全连接队列的所能容纳最大值，
如果，Recv-Q 大于 Send-Q 那么大于的那部分，是要溢出的即要被丢弃overflow掉的。
感想：
1本来想写TCP连接的建立和终止的，没想到要讲清楚TCP连接的建立已经很大的篇幅了，就只讲TCP连接的建立而已。
2以前看书的时候，没有解决一个问题的来的深刻或者说脉络清晰，这个就是主题阅读的好处吧。
3以前没有养成一个遇到问题深入解析，解决问题的习惯，今后慢慢养成。
下面的参考1有实例，会比较详细一点，清晰一些。
参考：
>