F5 会话处理流程描述参数说明及QA0120.docx
《F5 会话处理流程描述参数说明及QA0120.docx》由会员分享，可在线阅读，更多相关《F5 会话处理流程描述参数说明及QA0120.docx（30页珍藏版）》请在冰豆网上搜索。
F5会话处理流程描述参数说明及QA0120
F5会话处理流程（参数说明）及Q&A
一.TCP状态转换图
1、建立连接协议（三次握手）
（1）客户端发送一个带SYN标志的TCP报文到服务器。
这是三次握手过程中的报文1。
（2）服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。
因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。
（3）客户必须再次回应服务段一个ACK报文，这是报文段3。
2、连接终止协议（四次握手）
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。
这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。
收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。
首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。
和SYN一样，一个FIN将占用一个序号。
（3）服务器关闭客户端的连接，发送一个FIN给客户端。
（4）客户段发回ACK报文确认，并将确认序号设置为收到序号加1。
3、连接状态说明
CLOSED:
这个没什么好说的了，表示初始状态。
LISTEN:
这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_RCVD:
这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。
因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT:
这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。
SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED：
这个容易理解了，表示连接已经建立了。
FIN_WAIT_1:
这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。
而这两种状态的区别是：
FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。
而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2：
上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT:
表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。
如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING:
这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。
正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。
但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。
什么情况下会出现此种情况呢？
其实细想一下，也不难得出结论：
那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT:
这种状态的含义其实是表示在等待关闭。
怎么理解呢？
当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。
接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。
所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK:
这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。
当收到ACK报文后，也即可以进入到CLOSED可用状态了。
二.F5TCP连接管理及参数说明
1.F5TCP建立过程及相关参数说明
如图：
StandardVS/TCPProfile的连接建立过程
如图：
StandardVS/TCP/HTTPProfile（七层应用）的连接建立过程
2.F5TCPRST过程及TCPPORFILE中Resetontimeout选项
F5VS收到任何一方会话中发送的RST包，F5VS行为为立即转发，并清除F5中本会话连接。
TCPPORFILE中Resetontimeout选项,意为当F5VS中的会话超出idle超时时间值后，F5VS将向客户端、服务器同时发RST，并删除自身VS中会话链接。
此项默认值为启用状态。
3.F5TCP关闭过程及相关参数说明
下图是客户端主动发起关闭应用时的TCP连接关闭过程以及F5设备相应状态，总体上在这种情况下，F5会首先通过四次握手先关闭服务器端TCP连接，再关闭客户端连接．具体如下图所示：
下图是服务器端主动发起关闭应用时的TCP连接关闭过程以及F5设备相应状态，总体上在这种情况下，F5会首先通过四次握手先关闭客户端TCP连接，再关闭服务器端连接．具体如下图所示：
针对以上参数，F5设备上相关的配置项．
TimeWait
2000（缺省）
Options
Specify:
Userspecifiedamountoftime（inmilliseconds）thataTCPconnectionremainsintheTIME-WAITstatebeforeenteringtheCLOSEDstate
Immediate:
ThisoptionspecifiesthatthesystemclosestheconnectionimmediatelyaftertheconnectionenterstheTIME-WAITstateIndefinite:
ThisoptionspecifiesthatTCPconnectionscanremainintheTIME-WAITstateindefinitely
Thissettingspecifiesthelengthoftime（inmilliseconds）thataTCPconnectionremainsintheTIME-WAITstatebeforeenteringtheCLOSEDstate.
FinWait
5（Default）
Options:
Specify:
Userspecifiedamountoftime（inseconds）thataTCPconnectionisintheFIN-WAITorCLOSINGstatebeforeclosing
Immediate:
ThisoptionspecifiesthattheTCPconnectionclosesimmediatelyafterenteringtheFIN-WAITorCLOSINGstate
Indefinite:
ThisoptionspecifiesthatTCPconnectionsintheFIN-WAITorCLOSINGstatedonotquit
Thissettingspecifiesthelengthoftime（inseconds）thataTCPconnectionisintheFIN-WAITorCLOSINGstatebeforeclosing.
CloseWait
5（Default）
Options:
Specify:
Userspecifiedamountoftime（inseconds）thataTCPconnectionremainsintheLAST-ACKstatebeforequitting
Immediate:
ThisoptionspecifiesthattheTCPconnectionclosesimmediatelyafterenteringtheLAST-ACKstate
Indefinite:
ThisoptionspecifiesthatTCPconnectionintheLAST-ACKstatedonotcloseuntiltheymeetthemaximumretransmissionstimeout.
Thissettingspecifiesthelengthoftime（inseconds）thataTCPconnectionremainsintheLAST-ACKstatebeforequitting.
三.F5StandardVS/TCPProfile/StandardVS/TCP/HTTPProfile（七层应用）时间值及行为
产品：
F5bigip8400（OS:
9.3.1）
tcp-idle
-timeout
syn-timeout
rst
fin-wait
close-wait
time-wait
Persistence
StandardVS/TCPProfile/StandardVS/TCP/HTTPProfile（七层应用）
300s
与tcpidle-timeout相同
0秒
5秒
5秒
2s
60分（自定义）
四.F5VS异常场景行为及计时器的使用
场景
产品：
F5bigip8400（OS:
9.3.1）
tcp-idle-timeout
syn-timeout
rst
fin-wait
close-wait
time-wait
Persistence
StandardVS/TCPProfile/StandardVS/TCP/HTTPProfile（七层应用）
300s
与tcpidle-timeout相同
0秒
5秒
5秒
2s
60分（自定义）
场景行为&超时后行为
双向发RST
双向发RST
\
双向发RST
双向发RST
双向发RST
根据负载均衡算法，重新分发
1
异常情况下：
客户端发SYN--->F5SYN_ACK后，客户端不再发ACK包，F5对此会话如何处理（对客户端）？
自身对本会话如何处理？
F5此时对会话的响应所使用的计时器是那个，时间值是多少，即SYN－WaitTIMEOUT是多少？
这种情况f5会进入半连接状态,一直等到idletimeout超时（缺省设置为300s）,该计时器在tcpprofile中可定义.
不刷新
不刷新
\
\
\
\
\
2
针对TMOS9.3.1版本中,后台server全部down掉的情况下,客户端对F5VS进行建链请求，F5VS完成TCP三次握手后，立即向客户端发送RST包，此时，客户端同时向F5发HTTPGET请求，这时，F5对客户端后面这个HTTPGET请求，其行为是什么？
是否发Reset包?
（应用系统故障时，抓包，未看到后面的F5发的RST包）
1、F5在发出第一个RESET后，会立即清除自身的连接。
2、对于F5后续收到httpget请求，因没有匹配的session,F5会将该包丢弃.在9.3.1版本中，不再发RESET.
不刷新
\
\
\
\
\
\
3
正常状态下（F5VS、member服务器正常），客户端发RST包，F5的如何处理响应，对自身会话如何处理，计时器用那个，时间是多少？
同样，如服务器端发RST包，F5如何处理响应，对自身会话如何处理，计时器用那个，时间是多少？
如后续在此会话上，仍有相同的数据请求到达F5VS，F5如何处理响应，对自身会话如何处理，计时器用那个，时间是多少
无论是客户端还是服务器端发送reset给f5的VS,f5会立即清除相关的连接，没有相关联的计时器
\
\
\
\
\
\
\
4
正常状态下，在tcpprofile中选择resetontimeout后，F5到了tcp-idletimeout后主动向服务器端、客户端同时发rst并立即拆除session。
此时，如后续客户端有数据请求包到F5VS，而F5此时已清除了SESSION，那么F5如何响应客户端的请求，是发RST包给客户端，还是新建或直接丢弃？
计时器使用那个？
如果是新的连接（syn请求），重新建立连接；如果是其它状态的包，由于没有匹配的session,f5会将该包丢弃。
并且F5向请求方（客户端）发RST。
\
\
\
\
\
\
\
5
正常状态下（F5VS、member服务器正常），客户端与F5vs之间、F5与MEMBER（SER）均已完成建链，此时，后台MEMBER服务器服务PORTDOWN/UP,存在两种情况：
（F5的POOLMEMBERMONITORINTERVAL5sTIMEOUT16S）
A.如member的服务PORT在16S内（含）一直为DOWN状态
客户端后续数据请求包，F5如何处理响应？
F5vs本身对此SESSION的如何处理？
F5在是否会直接将后续请求包直接发给其他MEMBER?
还是F5VS保持与客户端当前会话，F5与其也MEMBER建链，然后，再将其转发至新VSMEMBER中？
还是F5会强制客户端重新建链，重新分配会话到其他MEMBER.
F5会清除原有session。
强制客户端重新建链，重新分配会话到其他MEMBER.
F5处理方法（双向发RST包，对客户端、服务器），对自身SESSION行为：
立即清除。
\
\
\
\
\
\
\
6
B.如PoolMember的服务Port在16S内（含）恢复UP服务状态
客户端后续数据请求包，F5如何处理响应？
F5vs本身对此SESSION的如何处理？
厂商回复：
F5会视作服务器正常，处理数据包行为没有改变。
\
\
\
\
\
\
\
7
F5VS为standar类型，VS中的MEMBER全DOWN后，VS对外仍提供会话建链，属F5正常机制（VS属性），非版本区别？
厂商回复：
正常机制，所有版本都是这种方式
\
\
\
\
\
\
\
8
F5VS收到FIN（首个FIN包，不区分服务器、客户端）后，转发给另一端（服务器或客户端），进行Finwait1状态，并进入5S的超时计时。
如首个FIN的ACK包未能在5S内收到，F5的行为是什么？
以什么行为向PC\SERVER拆链,即F5设备VS在FIN-TIMEout的动作行为。
厂商回复：
F5设备在fintimeout后如果在tcpprofile中选择resetontimeout后,会触发向客户端和服务器端同时发送reset数据包,同时删除相关连接表,如果不选择resetontimeout,F5设备只清除本地相关连接表,不做其它动作处理.
\
\
\
\
\
\
\
9
F5收到第一个FIN包（不管CLIENT\SERVER），FINTIMEOUT进入5秒超时计时，此值非绝对值，即如后续有包匹配SESSION，即触发TIMER重新计时?
这种机制是否对CLOSEWAIT计时器同等生效？
如CLOSEWAIT计时器与FINWAIT计时器刷新机制不一致，那么下面情况下，F5对会话的处理响应行为是什么？
\
\
\
等待中，数据包匹配，刷新重新计时
等待中，数据包匹配，刷新重新计时
等待中，数据包匹配，刷新重新计时
\
10
以客户端发起FIN为例，当F5收到CLIENTFIN后，进入CLOSEwait状态，并开始计时器倒计时，如F5与SERVER之间的两个FIN过程超出5S时或仍有数据传送，F5将会在CLOSEwait计时器倒计时5s后，根据上面的第一点的行为（选择RESETONTIMEOUT）,是否进行RESET双向拆链。
厂商回复：
无论是在close-wait,还是last-ack状态下都会进行5s倒计时。
超过该时间设定，resetontimeout拆连接。
\
\
\
\
\
\
\
五.F5Q&A
场景：
硬件：
F5big-ipLTM8400
软件：
9.3.137.1
VSTYPE:
主机VirtualServer
Profile:
StandardVS/TCPProfile/StandardVS/TCP/HTTPProfile（七层应用）
1、关于F5VS建立TCP会话时的TCP SYN包的处理行为Q&A
上面的截取的客户端与F5的TCP建链过程：
1）、正常情况下，F5的与客户端的完成三次握手的建链时间是多少（CLIENTSYN--->F5SYN_ACK－－CLIENTACK）？
厂商回复：
这个要根据网络的具体情况（延时,带宽等）而异,附件是我的一个正常访问的数据抓包,可以参考一下.
2）、异常情况下：
客户端发SYN--->F5SYN_ACK后，客户端不再发ACK包，F5对此会话如何处理（对客户端）？
自身对本会话如何处理？
F5此时对会话的响应所使用的计时器是那个，时间值是多少，即SYN－WaitTIMEOUT是多少？
厂商回复：
这种情况f5会进入半连接状态,一直等到idletimeout超时（缺省设置为300s）,该计时器在tcpprofile中可定义.
2、关于F5VS对会话中TCP RST数据包的处理行为
1） 针对TMOS9.3.1版本中,后台server全部down掉的情况下,客户端对F5VS进行建链请求，F5VS完成TCP三次握手后，立即向客户端发送RST包，此时，客户端同时向F5发HTTPGET请求，这时，F5对客户端后面这个HTTPGET请求，其行为是什么？
是否发Reset包?
（应用系统故障时，抓包，未看到后面的F5发的RST包）。
厂商回复：
F5对RST后收到httpget请求，因无会话将直接丢弃，在当前9.3.x版本，不会发rst包.（F5case：
CaseNumberC620307确认）
1、F5在发出第一个RESET后，会立即清除自身的连接。
2、对于F5后续收到httpget请求，因没有匹配的session,F5会将该包丢弃.在9.3.1版本中，不再发RESET.
2）正常状态下（F5VS、member服务器正常），客户端发RST包，F5的如何处理响应，对自身会话如何处理，计时器用那个，时间是多少？
同样，如服务器端发RST包，F5如何处理响应，对自身会话如何处理，计时器用那个，时间是多少？
如后续在此会话上，仍有相同的数据请求到达F5VS，F5如何处理响应，对自身会话如何处理，计时器用那个，时间是多少？
厂商回复：
无论是客户端还是服务器端发送reset给f5的VS,f5会立即清除相关的连接，没有相关联的计时器。
3）、正常状态下，在tcpprofile中选择resetontimeout后， F5到了tcp-idletimeout后主动向服务器端、客户端同时发rst并立即拆除session。
此时，如后续客户端有数据请求包到F5VS，而F5此时已清除了SESSION，那么F5如何响应客户端的请求，是发RST包给客户端，还是新建或直接丢弃？
计时器使用那个？
厂商回复：
如果是新的连接（syn请求），重新建立连接；如果是其它状态的包，由于没有匹配的session,f5会将该包丢弃。
4）、正常状态下（F5VS、member服务器正常），客户端与F5vs之间、F5与MEMBER（SER）均已完成建链，此时，后台MEMBER服务器服务PORTDOWN/UP,存在两种情况：
（F5的POOLMEMBERMONITORINTERVAL5sTIMEOUT16S）
A.如member的服务PORT在16S内（含）一直为DOWN状态
客户端后续数据请求包，F5如何处理响应？
F5vs本身对此SESSION的如何处理？
F5在是否会直接将后续请求包直接发给其他MEMBER?
还是F5VS保持与客户端当前会话，F5与其也MEMBER建链，然后，再将其转发至新VSMEMBER中？
还是F5会强制客户端重新建链，重新分配会话到其他MEMBER.
厂商回复：
F5会清除原有session。
强制客户端重新建链，重新分配会话到其他MEMBER.
F5处理方法（双向发RST包，对客户端、服务器），对自身SESSION行为：
立即清除。
B.如PoolMember的服务Port在16S内（含）恢复UP服务状态
客户端后续数据请求包，F5如何处理响应？
F5vs本身对此SESSION的如何处理？
厂商回复：
F5会视作服务器正常，处理数据包行为没有改变。
5）、F5VS为standar类型，VS中的MEMBER全DOWN后，VS对外仍提供会话建链，属F5正常机制（VS属性），非版本区别？
厂商回复：
正常机制，所有版本都是这种方式。
3、关于F5VS对会话中TCP FIN数据包的处理行为Q&A
1） F5VS收到FIN（首个FIN包，不区分服务器、客户端）后，转发给另一端（服务器或客户端），进行Finwait1状态，并进入5S的超时计时。
如首个FIN的ACK包未能在5S内收到，F5的行为是什么？
以什么行为向PC\SERVER拆链,即 F5设备VS在FIN-TIMEout的动作行为。
厂商回复：
F5设备在fintimeout后如果在tcpprofile中选择resetontimeout后
升级会员 