wireshark_1">一. 使用wireshark对百度进行抓包
进行抓包时, 需要得到ip(不知道怎么用域名). 我们可以通过nslookup baidu.com得到百度的ip, 然而, 在浏览器里访问baidu, ip不是这个命令得到的其中之一, 那么我在浏览器访问baidu.com后怎么在wireshark里找?
我的解决方法是, 在浏览器里不直接输入baidu.com进行查找, 而是输入刚刚查找到的ip, 访问的结果就是baidu.com, 但用这种方法我们可以在wireshark中过滤这个ip. 如图所示
https://img-blog.csdnimg.cn/201909131829002.png" alt="在这里插入图片描述" />
https://img-blog.csdnimg.cn/20190913182528260.png" alt="在这里插入图片描述" />
比如在我这里搜索到的百度的ip是39.156.69.79和220.181.38.148, 那么我就在浏览器访问39.156.69.79/s?word=python, 就在wireshark中过滤这个ip, 得到访问结果.
注意: 在wireshark中使用过滤规则如: ip.host == 39.156.69.79 限制抓取这个ip的包
https://img-blog.csdnimg.cn/20190913182449811.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
还有另一种找ip的方式, 那就是在浏览器检查里找到的baidu的ip. 但是经过测试这样找到的ip的抓包抓到的包有很多很多, 比上面那种多多了, 从包的协议来看, 第一种应该都是http, 而第二种应该是https. 我认为初学者可以先用前一种方法抓百度的包, 从简单的开始分析. (关于这个后面有个彩蛋)https://img-blog.csdnimg.cn/20190913182649777.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
http_16">二. 对http报文的分析
https://img-blog.csdnimg.cn/20190913184137836.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="" />
查看抓取的包, 有两个http协议, 其中第一个是我的ip发起的请求, 第二个是百度对我的回应.
https://img-blog.csdnimg.cn/20190913184403550.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
点进去, 查看详细内容, 可以看到这段http请求报文. 虽然和<<自顶向下>>书上的不完全一样, 但包含的信息是差不多的.
https://img-blog.csdnimg.cn/20190913184550500.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
这个是响应报文, 他给了我们一个302状态码, 维基百科的解释是这样的:
302 Found，原始描述短语为 Moved Temporarily ，是HTTP协议中的一个状态码(Status Code)。可以简单的理解为该资源原本确实存在，但已经被临时改变了位置；换而言之，就是请求的资源暂时驻留在不同的URI下[1]，故而除非特别指定了缓存头部指示，该状态码不可缓存。
对于服务器，通常会给浏览器发送HTTP Location头部来重定向到新的新位置。
这说明没有成功响应…
三. 理解响应失败的原因
所以我好像明白了什么, 因为使用第一个方法找到的ip访问时, 它似乎经过了一个重定向, chrome浏览器的锁那里先是显示不安全, 然后进入了baidu.com. 所以有理由认为使用nslookup命令找到的ip进入的服务器使用的是http, 并不安全, 于是自动重定向到了https.
而这也是我们最开始发现的, 第一种方法得到的包很少的原因了
于是我去验证一下, 在没有直接通过https的百度ip访问百度的情况下, 过滤该ip的包, 看是否有很多包. 事实确实是这样, http自动重定向到了https. 有很多的包.
https://img-blog.csdnimg.cn/20190913190057356.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
所以得出一个结论:
上面我介绍的第一种方法得到网站ip然后过滤抓包的方法是不可取的, 建议还是用在浏览器上用检查去获取网站的ip.
如图所示为加上ssl条件过滤, 协议都是TLSv1.2了
https://img-blog.csdnimg.cn/20190913190332347.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
tcp_44">四. tcp三次握手
然而我们的第一种方法完全没有价值吗? 并不, 前面说了, 它抓的包很简单, 而且是http协议. 书上介绍相关内容时, 是先从http介绍的, 因此我们可以用第一种在现在渐渐淘汰的http理解课本内容.
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主
动关闭连接之前，TCP
连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客
户端交互，最终确定断开）
如图所示, 三次握手建立起了tcp连接
https://img-blog.csdnimg.cn/20190913191112962.png" alt="在这里插入图片描述" />
出现了 SYN, ACK 这几个专业术语
https://img-blog.csdnimg.cn/20190913191724795.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dqaDI2MjIwNzUxMjc=,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
因此我们可以直观地感受到tcp建立连接的过程
这一次不是非常顺利但收获颇多的抓包学习，在抓包的过程中遇到好些问题，然后在解决问题的过程中发现自己的漏洞，和一些新的猜测并验证。
参考： https://www.cnblogs.com/tiwlin/archive/2011/12/25/2301305.html
