【读书笔记《Wireshark网络分析就这么简单》之三】

HTTP协议

HTTP工作方式是由客户端向服务器发出一个请求，再由服务器回复一个相应。根据不同需要，客户端发送的请求有不同方法，GET、POST、PUT和HEAD等。

1. 由于HTTP协议基于TCP， 三次握手先走起，先来三个包。
2. GET请求来下载页面内容。
3. 服务器对该请求响应，把页面内容发给客户端。
4. 客户端向服务器请求GET css，css用来定义页面格式。
5. 服务器对该请求响应，把css内容发给客户端。
   客户端通过两个GET方法，得到了WEB页面内容和格式，从而打开网页。

在WIRESHARK上右键单击抓的包，在弹出的菜单中选择Follow TCP Stream就可以打开这个窗口。

KERBEROS

1. AS_REQ 账号A—> KDC
2. AS_REP KDC—> 账号A
3. TGS_REQ 账号A—>KDC
4. TGS_REP KDC—>账号A
5. AP-REQ 账号A—>资源B
6. AP-REP 资源B—>账号A

案例1， 某客户可以用 ip地址来访问文件服务器，但是用域名就不行。

客户端用IP访问时用了NTLM做神风验证，用域名访问时则用的是Kerberos，两种验证方式机制不同。比如当客户端和服务器的时间没有同步时，Kerberos会认为该访问是重放攻击而拒绝访问，但NTLM不会。

案例2，一个账号明明加到某个组里，该组也被赋予访问文件夹的权限，但是该账号就是访问不了这个文件夹。

Wireshark解密AP_REQ之后，并没有看到这个组，让用户注销后再登录恢复。

案例3，某台客户端加入域失败

在包里发现KRB5KRB+ERR_RESPONSE_TOO_BIG的错误信息。

抓包案例学习：
重传不一定是乱序引起。
接收方已经收到Seq20440，为什么还要连发4个Dup ACK?
RFC里描述快速重传，当接收方收到比期望值大的SEQ时，就要向发送方Ack它期望的Seq值，但也不是这个原因。
接收方电脑系统问题，把20440给移到26280后面了。

读比写慢，根本原因不在DATA DOMAIN本身。从datadomain出来后，在路上丢失，没有到达AIX。以为没有等到AIX的确认包，所以只能选择重传。大量不必要重传，全部重传，DUP ack包里并没有包括SACK包，来只重传未收到的包。启用SACK后速度飙升。

性能问题三板斧

1. statistics >>> Summary, 看那段时间的流量高不高
2. Statistics >>> Service Response Time >>> ONC- rpc >>> Program >>> Create stat 观察各项操作的service response time
   3 Analyze >>> Expert Info Composite 看看Error和warning里是否有报错。如果没有，说明网络没问题。