开发者学堂课程【企业运维之云上网络原理与实践课程：第二讲配套实验-访问四层&七层CLB场景对比】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/991/detail/14976
第二讲配套实验-访问四层&七层CLB场景对比
内容介绍
一、课题引入
二、实验准备
三、四层实验步骤
四、问题及答案
五、七层实验步骤
六、结尾
一、课题引入
点开这个实验室之后，这个界面，左边是此次相关的资源登录信息，以及云产品的这个资源信息，都会创建完之后展示在控制台上，右边是提供了一个 MC，类似web 的一个界面，打开这个里面浏览器它会自动的填入这个当前测试账号的一个用户名，然后复制这个密码。粘贴登录进去保存。
更新之后，可以看到当前这个实验室创建出来的一个控制台，里面就会有此次实验需要的资源。
此次实验我们会使用到三个资源，一台 CLB，还有两台 ECS, 在杭州地区实验室会创建好两台 ECS以及 CLB 和 SLB，传统负载均衡实例管理。这个 CLB 相关的信息在这里面可以展示的出来。先通读一下这个实验手册，首先这个架构是这台 CLB 后边挂载了两台 ECS，可以尝试在一台 ECS 上去直接访问这个 CLB 的 IP。为什么会有这个实验以及面目呢？
是因为现阶段可能有很多的业务部署，比方说自己的服务器上开放了很多的接口，但是接口之间可能会需要有相互调用，也就是 A 接口需要去调用这个 B 接口。这个 B 接口同样也是在这台机器有很多很像的机器，所以某台机器是有可能促进这种场景，就是 SUB 后面的 ECS，再直接去访问这个 CLB。
二、实验准备
实验室已经创建好了相关的资源，包括一台 CLB 和两个 ECS。
注:后台已创建好了对应的云产品资源，这里仅了解和核实环境和相关配置。
如下仅供学员了解和参考，不需要去手动创建(如了解，可跳过):
1、创建 ECS 参考文档:
https://help.allyun.com/documynt_detall/25422.html
2、私网 CLB 实例创建 参考文档:
https://help.allyun.com/document_detall/86454.html
三、四层实验步骤
1.按照实验的步骤 steps 的方式去操作。首先登录到后端 ECS 上。直接看这里的一个 IP 地址，或者说在控制台上也能直接看到这两台 ECS 的 IP 地址，然后复制密码也是实验室动态生成的，密码直接复制出来登陆。
2.为了操作方便在两台机器上，为了方便查看首先装一个 nginx，因为刚才提到后端 ECS 上肯定需要有一个业务程序，为了演示方便直接使用 yum 这个工具 install nginx 这个机器系统是 stall nginx 安装软件用 yum install nginx 可以非常快的按照默认的方式去装好一个插件,
然后第二台机器也是类似,169.12选择 yes，密码不见了可以重置或通过远程连接重置密码，看一下这台机器安装情况，试一下两台密码是否相同。
3.做第一台机器的动作首先装好 nginx 为了方便访问将 nginx 默认首页稍微改一下。
比如进入 nginx 默认根目录 share nginx html 下面 html 就是正常访问机器得到的主页。
试一下这台机器的地址，先改一下主页地址为了便捷去分辨访问的是那台机器以 hostname 这个方式去改地址，这个时候再去看一下这个机器的文件，可以看到它的主页就变成了这个(izbp192zkdpoxpvprv5f8z)，这个实际上是这台机器的 hostname，再看一下另外一台机器，因为账号共享，有可能是其他同学也打开了这个账号所以会看到四台机器，就下面这两台是此次在操作的示例，上面两台是其他学员操作的，只去操作左边提示的这两台机器。
注意一下，就是第二台机器密码暂时不会展示出来，直接在控制台上找到对应的这个示例，做一次密码重置重启的动作。第二台机器也是类似的。
Yum install nginx 先把 nginx 装起来。然后Yes。在进入到默认的 share nginx html 同样的 hostname index.html 然后再 cat index.html 这台机器，可以非常明显看到两台机器他的 index 不一样的，一个是5f8z 结尾的，一个是 wgmz 结尾的。
4.进行下一个步骤，是安装 nginx，同时去修改 nginx 默认的主页文件。这里漏了一个步骤，就是最后要把 nginx 服务启动起来，也就是刚才为什么正在进行访问 IP地址访问不了的原因。
是因为这台机器内部没有监听自然就不能访问，把他启动一下通过 netstat 看一下监听情况，启动后再回来访问，可以看到访问第一台机器，我们就得到了5F8这么一个信息，就是刚才在系统内通过 host name 打进去的这个地址，另外一台也是类似。可以看到 wgmz 这台机器。两台机器现在都是正常对外进行访问。
5.再回到 SLB 的这个界面。来操作 CLB。CLB 点进去，首先要创建接听，前面提到了任何的服务都是以监听为为单位去提供服务的，因为这个实验是需要在四层和七层，这两种类型情况下都去做一些对比，那么先做 TCP 这个端口，为了和后面这个不重复，先选个808的端口，实际也可以根据自己的这个喜好来设置端口，根据电脑实验手册来做，先选默认服务器，其实为了服务器和监听两个动作是可以交互来做，先去加的服务器或者是先创建监听都可以，先加默认服务器，这两台是对应的刚操作的这台。
为什么是这台机器别人创建的机器加不进去，是因为他是一个VPC类型的实例，所以退回去实力详情，可以看到 CLB 关联到 BPC 上，另外一个同学创建的 ECS 和 CLB 是在另外一个 BPC 内然后目前的 BPC 类型的 LB 是无法跨越 BPC 挂载，也就是这个 BPC 只能挂在这个 BPC 里面的 ECS 。添加服务器。选中执行，确定。加完之后回过来创建监听。然后高其特性的按照默认的不去动，其实前面讲到的很多信息都可以在这边看到，比如说这个会话保持，然后访问控制，还有这个PP的协议配置都可以在这里看到。
6.这一步就是之前截图 PPT 里截图的一个点，因为刚才已经加了两台机器到默认服务器组内，所以这里可以直接进行配置，如果刚才没有做，那么其实可以点添加，直接加服务器。八零端口，刚才 nginx 监听端口是自己填上八零端口，也就是 CLB收到连接之后，将这个链接会转到后端 Ecs 的八零端口上，和他进行三次握手和通信。
7.再点这个健康检查，默认情况下是要开起来。以保证 CLB 能时时的知道后端 ECS 的情况，现在因为是要做实验，后面还需要做抓包，为了避免健康检查流量的一些影响，这里把它关闭。正常情况下是要开启的，只是为了现在观察方便把它关闭。下一步这个是检查，再次检查这个配置是否无误，没有问题，点提交。这个监听就创建好了，再去创建第二个监听，这个8080的 HTTP 监听，刚才这里实验手册里面提到这个8080端口，然后前面这里创建的是808，严格按照实验手册来操作。
80下一步关闭，下一步提交。然后再把808这个监听给删掉。在建监听HTTP8080同样是默认服务器组80。这个步骤稍微改动一下，就是创建监听依次的进行。这里实验手册里面两个监听一起创建的，但是在后边做抓包的时候可能会相互影响，因为会有同时有 TCP 和 HTTP 两个接听同时在进行操作，虽然说对实验最终的这个结论或者说过程没有影响，但是可能会影响他的效果，那么先对八零端口进行一些观察。
8.下一页，这时是需要做的一个动作，就是在机器内部，比方说这台机器是 ECS1去访问这个 CLB 的 IP 地址，这个直接在实例管理看，
把ros-LoadBalancer-stack…lb bp12byewygmiqiqcsdood 192…168.0.238(专有网络)vpc. Bp1y5stxkzcy620hpzta vsw.
Bp1005xynqbqy82ttrg 复制到这里就不会忘记了，系统里可能没有装 telnet,同样用yum来装一下，现在要做的事情根据实验手册描述的在 ESC1上安装 telnet 以便访问4层 CLB 的80端口，同时在 ECS1内部抓包，先进行访问看一下实际表现是怎样的192.168.0.238.80端口，第一次发现联不通 Ctrl+C 再来一次结果变成了Connected to 192.168.0.238. 然后给了一个退出提示，这个就表示连上的目标端口，然后再退出。
进行第三次发现又连不通了，重复多次发现它时通时不通，这是今天实验一个重点。这个时候需要通过抓包这个工作进行分析。再开一个窗口。提醒一下在第一讲中提到的一个工具 tcpdump 他是在 loading 环境下进行抓包观察的一个工具。在截图中应该会有体现，（root@ECS1-]#tcpdump-nni any part80 and not net100.6在这，首先需要明确的是，需要抓的是 any 网卡。同时抓八零端口，因为后端监听的端口就是80，然后在这里其实还带上了一个是 and not net100.64.0，这个过滤条件表示就是过滤去除100.64这个网站的地址，为什么会有这个信息呢？
其实就是为了如果前边健康检查有没有关闭。带上这个信息之后，就可以过滤掉健康检查的流量，但是现在这边健康检查没有开启是不会抓到健康检查流量。
将抓包工具敲进去这个命令就开始抓包了，前端先进行第一次的访问，这次记住它是一个无法连接的情况，把它 ctrlC 断掉，同时继续分析抓包里边的一个表现。
可以把它复制到一些工作工具里面去看。首先可以看到这里客户端是237，为了方便再拼一张截图。把 ECS 拼出来，机器是这两台，那么对应的示例就是这两个实例。把它拼在这里，方便查看。
对直接看这个也没问题首先是237客户端向 SLB238发起了S包这个时候其实在客户端这一侧他的表现是无法连接的，为什么？继续看这个抓包，这里重复出现S包，接着回了 sack 包，最后出现了 rest 包，过来一秒钟之后我得 S 中传这块可以分割成两块，前面这一节是完整的表现，之后因为中传表现都是类似的。每一节都是现场表现，那只分析前面这一节，这一节首先想第一个问题为什么有两个 S 包明明三次握手规则发了个 S 然后回了Sack再回ack就完成了但是20：35：
40.224529 IP 192.168.0.237.47966>192.168.0.237.80:Flags[s]详细内容这里没有展示，实际他的来源不一样，再给他做一个详细的抓包，终于到了不同的结果，从这里开始看这个 S 包
（20：39:27.923720 0ut 00:16:3f:00:94:40 ethertype IPv4(0x0800),length 76:(tos 0x10,ttl 64, id 62398, offset 0, flags[DF],proto TCP (6),length 60)
192.168.0.237.47986 >192.168.0.238.80:Flaqs[S]，cksumx835a(incorrect ->0x0bd3),seq 2404934922, win 29200,op ons [mss 1460,sackok,TS val 1545908 ecr 0,nop,wscale 7],length 0
39:27.923879 In ee:ff:ff:ff:ff:ff ethertype IPv4 (0x0800),length 76:(tos 0x10,ttl 64, id 62398, offset 0, flags，proto TCP(6)，length 60) (这个原IP原 mac 网卡看不出来)到了下面这个
192.168.0.237.47986 >192.168.0.237.80:Flags [S]，cksum 0x0bd4(correct), sea 2404934922. win 29200, options [mss i I,sackok,Ts val 1545908 ecr 0,nop,wscale 7],length 0
39:27.923894 In 00:00:00:00:00:00 ethertype IPv4(0x0800),length 76:(tos 0x0,ttl 64, id 0, offset 0,flags [DF], oto TCP(6),length 60)（同样也是装了网卡）
192.168.0.237.80 >192.168.0.237.47986:Flags[scksum x8359(incorrect -> 0x76a8),seq 213761747, ack 240493492 win 43690, options [mss 65495,sackokTS val 1545908 ecr 1545908nopwscale 7], length 0
239:27.923903 In 00:00:00:00:00:00 ethertype IPv4(0x0800),length 56:(tos 0x0, ttl 64, id 41147. offset 0, flaas [
to TCP(6), length 40)
.168.0.237.47986 >192.168.0.237.80:Flags[R]，cksum0x7c8f(correct),seq 2404934923, win o,length 0)
希望通过一次性的抓包来看到多张网卡的表现，但因为现在是 any 和 Linux 内核一些逻辑，通过 any 网卡抓包出来的二层投它实际上是不完整的，它只能表现出一种特征，就是这个包是发送给谁，或者说是来从谁那儿来的。简单来说，这个S包实际上是经过 CLB 转发之后，他从远端收到的包。
现在ECS1服务器上去访问的 CLB IP 地址。那么 CLB 经过 CLB 转发，他这个流量自然还会转发给后端的 ECS，那么在问题的等发生的时候，这个S包实际上是被再次转发给了 ECS1这台机器，所以才会出现刚才我们这种表现，就是客户端本身发了一个 S 包，但是这个S包经过 CLB 转发，再次转发给了这台本机。在本机看到S包的时候，很自然而然的会回sack，因为这是内核协议站规定的动作，但是这个sack，因为目标 IP 是237这个地址。根据 Linux 的旋路原则这个包直接被系统内自动捕获。还是拿 PPT 来将更加清楚.
四、问题及答案
1.这四个包为什么会这样？
首先聊到了 sack 包，他的目标地址也就是本机地址，然后去路由因为这台机器的IP地址目标是在这台机器上的，所以并不会绕过其他的。这个模块是在机器内部自己处理，但是此时 Linux 内核去看他的系统内并没有这么一个五元组的 socket ，所以他回了一个 reset，就正常情况下，收到的 Sack 包之后说明之前已经有一个对应的 s 的五元素出现了，但是因为这其中 CLB 他做了一个 net 转换，之前的五元组是这个192.168.11.173.48092>192.168.11.175.80，一边是173一边是175。
但是收到的这个 sack，它两边都是173，然而这个系统没有这个五元组和这里的对不上。所以最终内核回了 reset，但是这里还有一个问题，就是实际上这个 sack 包是没有经过 CLB，它是直接就直接回给了自己所以站在 CLB 的角度上来看，它只是转发了一个 sack 胞，之后他就没有收到更多的包，剩下的这个包的转发都是在系统内进行。再看一下，最开始发的 s 包从这台机器里面出去了，原路是这样的经过 CLB 转发之后到达后端因为CLB上有TUA模块的加成同时有 net 转换。它的后端IP变成了这个 IP，也就是从175转到了173。那么可以被这台机器正常的处理，回复了sack，但是因为此时目标IP已经被改写成了173，所以回 sack 的这个地址。
两边都是173。返回之后就自然而然的，因为没有元组，所以内核就给了一个reset。这个连接就没有发生的建立。
2.另外为什么它时通时不通？
可以再做一次简单的抓包。通的现场可以看到237发给了238也就是这台机器237发给了 SLB 然后他收到来自远端的 sack 这个地址依然是238，然后回了 sack 和异常情况下他是有区别的，所谓区别就是没有收到 sack 包，这个 sack 包去哪了，自然去了第二台机器 ECS2，也就是说能访问通的时候，实际上 sack 包经由 CLB 转发给了 ECS2，那么ECS2实际上没有类似五元组，然后IP地址也不是自己的 IP 地址所以可以正常处理它，sack 然后 ECS1又可以正常处理。所以才会导致时通时不通的情况。不通的时候sack包转发给了自己，通的时候转发给了其他人就不会有五元组冲突的问题。这个操作可以再反复的进行，甚至也可以将抓包工具让他保存成这个具体的文件，然后再倒出来，通过往下进一步的去研究，去体会它其中的这个地址转换的过程。四层表现就是这样。
五、七层实验步骤
到了七层在控制台上重新创建监听，在配置完了之后，同样是在这台机器上，通过 curl 去访问。这里要注意为什么不通过 telnet 去访问？这也是实验手册上提供的提出的第一个问题，为什么使用 curl 而不使用 telnet 这里可以思考一下。
用curl去请求192.168.0.238：8080因为使用的是飞镖端口所以需要显示的指令，可以看到访问是成功的，同时返回的是 ECS2的信息，不断访问。刚才四层的情况，用 telnet 去探测是时通时不通的一个表现，那么换成了七层监听，可以发现，在同一台机器上是始终都能获得结果，同时两台机器都可以均衡的返回结果。
那么这又有一个问题，为什么在七层上，这样子的架构是没有问题的？那么还是通过抓包来看。这里有一点要注意，就是前面提到的七层监听，他的原 IP 来源 IP 全部都100网段的，比如说这一次抓包他的原IP就是100.122.64.142，这个地址。
这里实际是 CLB 转发收到的一个结果。那么还是实际的进行抓包。这次抓包可以只抓1t70，因为正常情况下他后端通信的地址都是100地址只会在1t70上进行，那么刚才为什么说安妮网卡呢，因为像这个包（192.168.0.238.80>192.168.0.23748000）在回包的时候，因为地址是237自己的地址不会走1t70而会走Loop网卡。从内部走掉了所以如果走1t70会发现始终抓不全地址。填入代码 tcpdmp-nni eth0 part 80执行，100，100这个是机器内部他有云服务会定期请求，所以100，1001这个地址实际上都是广泛的运用阿里云网络的这个云服务地址，请求一次。注意现在是在F8台机器上请求，然后看这次的结果是返回的另外一台机器的信息，从这里看一下，80端口但是实际上请求的是8080就带来一个问题，那 or port 8080,在访问一次。找到最开始的有100地址的 sack 包就是这个
20:55:37.431497IP 192.168.0.23760106 >19216.208:Flags[]se3623904962, win 29200, options [mss 1460,sac kOK,TS val 2515416 ecr 0,nop,wscale 7], length 0
20:55:37.431710IP 192.168.0.238.8080>192.168.0.23760106:Flagsseq3010406911 ack3623904963, win 29200, opti ons [mss 1440,nop,nop,sackok,nopwscale 9]，length 0
20:55:37.431724 IP 192.168.0.237.60106 > 192.168.0.238.8080: Flaas [.l. ack 1. win 229, lenath 0
20:55:37.431985 IP 192.168.0.237.60106>192.168.0.2388080:Flags[Pseq1:83ack1win 229,length 82: HTTP: GET/HTTP/1.1
20:55:37.432118 IP 192.168.0.238.8080>192.168.023760106:Flags [], ack 83, win 58, length 0
20:55:37.432828 IP 192.168.0.238.8080 >192.168.0.23760106:Flas[Psea 1239ack83 win 58,lenath 238: HTTP;HI TP/1.1 200 0K
20:55:37.432834 IP 192.168.0.237.60106>19208Flags], ack 239, win 237, length 0
20:55:37.432956 IP 192.168.0.237.60106 >192.168.0.238080:FlasFse8ck239 win 237, length 20:55:37433241 IP 192.168.0.2388080>190106lagsFse239ack84 win 58, length 020:55:37.433248 IP 192.168.0.23760106 >1921682800Flags], ack 240, win 237, length 0
20:55:37.499318 IP 192.168.0.23744124>100.100302580Flags[Pseq1700:2294,ack11 win 372,length 594: HTTP20:55:37,501138 IP 100.10030.25.80>1928034lasck229win 1424 length 0^C
把他复制出来，注意这一次请求的面目是 ECS1请求 CLB 的 IP 地址，然后这个连接被转发到了另一台机器那么自然而然前面这三个237到238CLB完成之后，237向238发了一个 get 请求可以看到由 curl 产生的 get 请求这端回了 ack，同时返回了对应内容。之后这个结果，关闭链接没有问题，这个就是一个很标准的这一个过程，再重新抓一次，争取抓到一个自己访问自己的这个情况。抓到了往前回溯，为什么？其实这两种场景下唯一的区别，就是再第二个场景下curl发出的get请求是同样回到自己的机器上，那么会多出什么信息？会多出CLB转发的信息。在这后边其实可以看到有来自100网段的地址100.97发来个s这个就是最开始 ports 也就是 nginx 进行的第一个转发包就是三次握手，然后同样会收到来自100地址段转发的 get 请求，这个请求就是上面的请求。还是抓起来直接看。可以大致分为三段这是第一段
120:56:55.988519 IP192.168.0.237.60120>192168230lase2844777win29200,options [mss 1460,sackoK,TS
val 2593973 ecr0nopwscale7]，length 0
220:56:55.988708 IP 192.168.0.238.8080>192163012lagse14930605ck284777win 29200, options[mss 1440,nopnopsackoKnopwscale 9]，length 0
320:56:55.988721 IP 192168.0.23760120>198lasckwin22length
4
520:56:55.988858IP 192.168.0.237.60120 >192.168.02388lagsPs1:8ackwin 229length
这是第二段
620:56:55.988858IP 192.168.0.237.60120 >192.168.02388lagsPs1:8ackwin 229length 82: HTTP GET / HTTP/1.1
7
820:56:55.989004IP 192168.0.238.8080>192.168.0.237012Flasack83 win 58 length 0
20:56:55.989166IP 100.97.134.22.10064>19216803lagsse277930in288options [mss 1424,sackok,s val 2936768630 ecr 0nopwscale9]，length 0
920:56:55.989175IP 192.168.0.237.80 >100.97.134.2210064:Flagsse38270961ck2779in28960, options [mss 1460,sackoKTS val 2593973 ecr 2936768630nopwscale 7length 0
1020:56:55.989269IP 100.97.1342210064>192168.023780:Flagsackwin56, options [nopnopTS val 2936768630 ecr 2593973]，length 011
这是第三段
11
12 20:56:55.989280 IP 100.971342210064>19223lagsse115ackwin 56, options [nopnopTS val
2936768630 ecr 2593973]，length 158:HTTP:GET/HTTP/1.1
13 20:56:55.989284 IP 192.168.0.237.80 >100.97.134.22.10064:Flagsack159win 235options nopnopTS val 2593974 ecr 2936768630]，lenath 0
14 20:56:55.989421 IP 192.168.0.237.80>100.9713422006FlagsFP，seg1256ack15win235,options [nopnop,TS val
2593974 ecr 2936768630]，length 255:HTTP:HTTP/11 200 0K
15 20:56:55.989936 IP 100.97.1342210064>192.168.023780:FlagsFse159ack257win58 options [nopnopTS val
2936768630 ecr2593974]，length 0
16 20:56:55.989942 IP 192.168.0.237.80>100.97132100lagsck16win235optionsnopnopTS val 2593974 ecr 2936768630]，length 0
首先第一段237地址机器向238CLB发送curl请求，首先三次握手成功建立好之后237通过 curl 发送 get 请求，对端CLB@一下表示收到。
之后就会有些差别，实际上这次请求是被转换发给了自己给了ECS1此时这台机器就会收到来自CLB转发请求由100端开始建联接着转发了这个
20:56:55.989280 IP 100.971342210064>19223lagsse115ackwin 56, options [nopnopTS val 2936768630 ecr 2593973]，length 158:HTTP:GET/HTTP/1.1 get请求，这一请求
实际上就是前面这个包经过CLB转发然后机器给了 ack 之后返回响应最后在经过转发后面还有一个是（20：56：55.989949IP 192.168.0.238.8080>192.168.0.237.60120：Flags[p.],seq1:239,ack83,win58,length238:Http:Http/1.1200 ok）192.168.0.237.80>100.9713422006FlagsFP，seg1256ack15win235,options [nopnop,TS val
2593974 ecr 2936768630]，length 255:HTTP:HTTP/11 200 0K这一行是机器返回给CLB的信息，之后CLB关闭了链接最终CLB转发之后再把这个数据包转发给这台机器就完成了CLB转发请求相应的一个动作。
六、结尾
为什么后端机器有这么多特征，这是 [FP] 还有 ack 等于说一个关闭连接的包装会同时带有数据，或者反过来说数据包里面同时关闭连接，为什么？是因为这种情况下，CLB 在转发过程中是短连接，在请求的头里边，Connection 这个字段是 close，这里体现不出来，后面抓的时候可以抓下来，在 wshy 中打开就可以看到这个请求是 close，那么这个机器 web server 就知道说这是一次短连接，在给足响应之后是势必要关闭连接的，为了节约包销户，他一次性的做了才会响应和关闭连接两个动作。为什么这一次请求是自应自答，但是能正常得到结果的。而四层监听，在类似的情况下是拿不到结果的，这是此次试验最关键的一个动作，要思考两个监听下。CLB 转发的时候他的具体这个逻辑是怎么样？
再回想一下刚才那个动作和现在这个动作有什么差别，是中间出现了一个100地址段的代理服务器，也就是这台机器似乎是在和两个机器在做通信，一个机器是238，一个机器是100的地址，所以他们两者之间不会再有刚才提到的这个五元组冲突的情况，我的一个五元组是这个（192.168.0.237.60120>192.168.0.238.8080），第二个五元组是这个（100.97.134.22.10064>192.168.0.237.80）。虽然说实际上作为客户端和服务端但是CLB中间夹了七层转发模块，所以他的五元组是不同的两组，那么在 Linux 内核转发下是可以正常的工作，这是此次实验最核心最关键的一个动作，是需要了解七层下中间是有一个七层代理做转发他的源地址100网段，四层是完全的透明的，似乎看到的是自己的IP过来的地址，那么回包的时候，自然的直接就是回给自己不经过 CLB，同时就导致了上面这些问题。大概这次实验它的核心内容就是上面讲的这些核心就是为什么在四层监听下后端的 ECS 是不能直接访问前端的这个 CLB，如果说业务上面需要有这样子的访问，建议也可以改用七层，或者尽可能在业务上不要有这样子的回环的这种访问的形式。
四层监听 PingCLB 这个会一直没有问题的，前面说的 telent 是要进行三次握手之后，这个包才会真正的到达，获得 ECS，如果去 ping。比方说在这 ping 在后台抓包。那就装 nni 网卡只能抓到自己的程序或者在另外一台机器也可以转，这是两台机器一个是5F8一个是这个东西，抓包在持续，可以看到虽然 ping 在持续但是只抓到两个包另外机器没有抓到包，也就说明了 ping 包实际是 CLB 的机器带回的他的流量是终结在 CLB 上，不会脱什么后端如果来进行探测必须要使用 telnet。
同时再深一步来说明，为什么刚才七层监听它需要用curl来进行。因为七层监听他是一个 HTTP 侧面的动作，如果只用 telnet net 来测试呢？
建联好了之后，实际上客户端只和 CLB 的 proxy 机器进行连接，没有发起任何数据的时候 CLB 在部分机群是不会向后端 ECS 进行连接，必须用 curl 发送七层数据， CLB 机群才会向后端 ECS 进行连接探测转发。
