开始新对话

未解决

此帖子已超过 5 年

507254

2014年8月10日 18:00

网络基本功系列:细说网络那些事儿(3月26日更新)

网络基本功(一):细说网络传输

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

常言道:欲练神功,必先练好基本功。之前做了一个关于IP路由,默认网关和掩码的问答贴,做完这个帖子觉得如果对网络知识点做一个系统的阐述,应该会很有帮助。


本系列文章着重于讲解网络管理实际应用中常常涉及的重要知识点,尽量以实用为主。准备写的几个章节暂时有(可能会有增减):



更多信息


首先来看一个例子:


示例:网络服务器向客户端传送数据的过程:

在详细阐述网络传输过程之前,先来看一个最常见的例子,下图显示了一个网络服务器向客户端传送数据的完整过程:

image002.jpg

     1.     需要传送的数据是网络服务器的HTML页面。

     2.     应用协议HTTP报文头添加到HTML数据之前。报文头信息包括:服务器所使用的HTTP版本,以及表明它包含发给网络客户端信息的状态编码。

     3.     HTTP应用层协议将HTML格式的网页数据发送给传输层。TCP传输层用于管理网络服务器和客户端之间的会话。

     4.     IP信息添加到TCP信息之前。IP指定适当的源和目的IP地址。这些信息就构成了IP报文。

     5.     以太网协议添加到IP报文的两端之后,就形成了数据链路帧。上述帧发送至通向网络客户端的路径上的最近一个路由器。路由器移除以太网信息,观察IP报文,判定最佳路径,将报文插入一个新的帧,并发送至目标路径上下一个相邻路由器。每一个路由器在转发之前都移除并添加新的数据链路层信息。

     6.     数据通过互联网络传输,互联网络包含媒介和中间设备。

     7.     客户端接收到包含数据的数据链路帧,处理各层协议头,之后以添加时相反的顺序移除协议头。首先处理并移除以太网信息,之后是IP协议信息,接下来TCP信息,最后是HTTP信息。

     8.     之后,将网页信息传递给客户端网页浏览器软件。

数据封装:

消息要在网络中传输,必须对它进行编码,以特定的格式进行封装,同时需要适当地封装以足够的控制地址信息,以使它能够从发送方移动到接收方。

消息大小

理论上,视频或邮件信息是能够以大块非中断型流从网络源地址传送到目的地址,但这也意味着同一时刻同一网络其他设备就无法收发消息。这种大型数据流会造成显著延时。并且,如果传输过程中连接断开,整个数据流都会丢失需要全部重传。因此更好的方法是将数据流分割segmentation)为较小的,便于管理的片段,能够带来两点好处:

·         发送较小片段,网络上同时可有多个会话交错进行。这种在网络上将不同会话片段交错进行的过程称为多路传输(multiplexing

·         分割可提高网络通讯的可靠性。各消息片段从源地址到目的地址无需经过相同路径,如果一条路径被堵塞或断开,其余消息可从替换路径到达目的地址。如果部分消息到不了目的地址,那只需重传丢失部分。

通过对片段打上标签的方式来保证顺序以及在接收时重组。

image003.jpg

协议数据单元(Protocol Data Unit, PDU

应用层数据在传输过程中沿着协议栈传递,每一层协议都会向其中添加信息。这就是封装的过程。

数据片段在各层网络结构中采用的形式就称为协议数据单元(PDU。封装过程中,下一层对从上一层收到的PDU进行封装。在处理的每一个阶段PDU都有不同的名字来反应它的功能。

image004.jpg

PDU按照TCP/IP协议的命名规范:

·         数据(Data:应用层PDU的常用术语

·         分段(Segment):传输层PDU

·         帧(Frame):网络层PDU

·         比特(Bits):在介质上物理传输数据所使用的PDU

封装

封装是指在传输之前为数据添加额外的协议头信息的过程。在绝大多数数据通信过程中,源数据在传输前都会封装以数层协议。在网络上发送消息时,主机上的协议栈从上至下进行操作。

以网络服务器为例,HTTP应用层协议发送HTML格式网页数据到传输层,应用层数据被分成TCP分段。各TCP分段被打上标签,称为头(header),表明接收方哪一个进程应当接收此消息。同时也包含使得接收方能够按照原有的格式来重组数据的信息。

传输层将网页HTML数据封装成分段并发送至网络层,执行IP层协议。整个TCP分段封装成IP报文,也就是再添上IP头标签。IP头包括源和目的IP地址,以及发送报文到目的地址所必须的信息。

之后,IP报文发送到接入层,封装以帧头和帧尾。每个帧头都包含源和目的物理地址。物理地址唯一指定了本地网络上的设备。帧尾包含差错校正信息。最后,由服务器网卡将比特编码传输给介质。   

解封装

接收主机以相反的方式进行操作称为解封装。解封装是接收设备移除一层或多层协议头的过程。数据在协议栈中向上移动直到终端应用层伴随着解封装。

访问本地资源:

访问本地网络资源需要两种类型的地址:网络层地址和数据链路层地址。网络层和数据链路层负责将数据从发送设备传输至接收设备。两层协议都有源和目的地址,但两种地址的目的不同

示例:客户端PC1FTP在同一IP网络的通信

image005.jpg

网络地址

网络层地址或IP地址包含两个部分:网络前缀和主机。路由器使用网络前缀部分将报文转发给适当的网络。最后一个路由器使用主机部分将报文发送给目标设备。同一本地网络中,网络前缀部分是相同的,只有主机设备地址部分不同。

IP地址:发送设备,即客户端PC1IP地址:192.168.1.110

目的IP地址:接收设备,即FTP服务器:192.168.1.9

数据链路地址

数据链路地址的目的是在同一网络中将数据链路帧从一个网络接口发送至另一个网络接口。以太网LAN和无线网LAN是两种不同物理介质的网络示例,分别有自己的数据链路协议。

IP报文的发送方和接收方位于同一网络,数据链路帧直接发送到接收设备。以太网上数据链路地址就是以太网MAC地址。MAC地址是物理植入网卡的48比特地址。

MAC地址:发送IP报文的PC1以太网卡MAC地址,AA-AA-AA-AA-AA-AA

目的MAC地址:当发送设备与接收设备位于同一网络,即为接收设备的数据链路地址。本例中,FTP MAC地址:CC-CC-CC-CC-CC-CC

源和目的MAC地址添加到以太网帧中。

image006.jpg

MACIP地址

发送方必须知道接收方的物理和逻辑地址。发送方主机能够以多种方式学习到接收方的IP地址:比如域名系统(Domain Name System, DNS),或通过应用手动输入,如用户指定FTP地址。

以太网MAC地址是怎么识别的呢?发送方主机使用地址解析协议(Address Resolution Protocol, ARP)以检测本地网络的所有MAC地址。如下图所示,发送主机在整个LAN发送ARP请求消息,这是一条广播消息。ARP请求包含目标设备的IP地址,LAN上的每一个设备都会检查该ARP请求,看看是否包含它自身的IP地址。只有符合该IP地址的设备才会发送ARP响应。ARP响应包含ARP请求中IP地址相对应的MAC地址。

image007.jpg

访问远程资源:

默认网关

当主机发送消息到远端网络,必须使用路由器,也称为默认网关。默认网关就是位于发送主机同一网络上的路由器的接口IP地址。有一点很重要:本地网络上的所有主机都能够配置自己的默认网关地址。如果该主机的TCP/IP设置中没有配置默认网关地址,或指定了错误的默认网关地址,则远端网络消息无法被送达

如下图所示,LAN上的主机PC 1使用IP地址为192.168.1.1R1作为默认网关,如果PDU的目的地址位于另一个网络,则主机将PDU发送至路由器上的默认网关。

image008.jpg

与远端网络设备通讯

下图显示了客户端主机PC 1与远端IP网络服务器进行通讯的网络层地址与数据链路层地址:

image009.jpg

网络地址

当报文的发送方与接收方位于不同网络,源和目的IP地址将会代表不同网络上的主机

IP地址:发送设备即客户端主机PC 1IP地址:192.168.1.110

目的IP地址:接收设备即网络服务器的IP地址:172.16.1.99

数据链路地址

当报文的发送方与接收方位于不同网络,以太网数据链路帧无法直接被发送到目的主机。以太网帧必须先发送给路由器或默认网关。本例中,默认网关是R1R1的接口IP地址与PC 1属于同一网络,因此PC 1能够直接达到路由器。

MAC地址:发送设备即PC 1MAC地址,PC1的以太网接口MAC地址为:AA-AA-AA-AA-AA-AA

目的MAC地址:当报文的发送方与接收方位于不同网络,这一值为路由器或默认网关的以太网MAC地址。本例中,即R1的以太网接口MAC地址,即:11-11-11-11-11-11

IP报文封装成的以太网帧先被传输至R1R1再转发给目的地址即网络服务器。R1可以转发给另一个路由器,如果目的服务器所在网路连接至R1,则直接发送给服务器。

发送设备如何确定路由器的MAC地址?每一个设备通过自己的TCP/IP设置中的默认网关地址得知路由器的IP地址。之后,它通过ARP来得知默认网关的MAC地址,该MAC地址随后添加到帧中。

             

1.2K 消息

2015年2月3日 23:00

谢谢支持!

6 消息

2015年2月3日 23:00

从头到尾挑自己感兴趣的看了一遍,支持下楼主

1.2K 消息

2015年2月5日 23:00

一般二层数据收发是通过主板上的二层交换芯片来完成的,通过软件实现协议栈理论上没什么问题,C语言就可以。但是会非常非常缓慢。。。

6 消息

2015年2月5日 23:00

有个问题想请教一下,比如说连接在同一台交换机下的多个设备,不管他们的IP地址是否相同或者不在同一网段,理论上如果二层通讯的话只需要知道mac地址就行了,那我考虑是否可以发送一个类似于arp的二层广播包(包数据自定义),收到这个自定义数据的二层广播包的设备回复自己的mac地址,这样就可以跟同一交换机下的能够理解这个自定义二层广播包的设备通信了,而不用管他们的IP是怎么设置的。不知道我的这个想法有没有问题?如果想法没问题的话,如何通过编程实现?(貌似对二层数据的封包和拆包是操作系统干的事情,难道像linux这样开源的要修改操作系统内核才能实现?还是有什么编程语言能够实现二层数据的收发,感觉不太现实啊),这些都是我看到有的交换机出厂默认IP都一样,可以用厂商提供的工具直接修改交换机的ip想到的,有点疑惑,所以想请教一下。

问题有点长

1.2K 消息

2015年2月6日 00:00

谢谢解答,那我看到的那些交换机是自己实现的协议栈可以理解,那windows上运行的这个软件我就想不明白了,可以通过何种方式实现呢?

问题我有点不太理解,是说二层以上的协议栈是如何实现的吗?协议栈嵌入在操作系统里,但也有网络处理器(NPU)通过硬件来实现上层封装。

6 消息

2015年2月6日 00:00

谢谢解答,那我看到的那些交换机是自己实现的协议栈可以理解,那windows上运行的这个软件我就想不明白了,可以通过何种方式实现呢?

大神真是秒回啊。。。。。。

1.2K 消息

2015年2月6日 00:00

不客气,有问题欢迎继续讨论~

6 消息

2015年2月6日 00:00

可惜只是看到,没有实际的设备和软件

6 消息

2015年2月6日 00:00

哦,有点了解了,我再查查相关的资料,谢谢

1.2K 消息

2015年2月9日 00:00

网络基本功(二十五):Wireshark抓包实例分析TCP重复ACK与乱序

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

TCP的一大常见问题在于重复ACK与快速重传。这一现象的发生也是由于性能问题,本章讨论如何发现这一问题以及他们意味着什么。

另一个常见问题是前一片段丢失以及乱序片段。某些情况下,这一现象喻示着故障发生,可能是由于网络问题或是抓包中断。


更多信息

重复ACK与快速重传:

当网速变慢时,重复ACK是可能的原因之一。大多数情况下,重复ACK的发生是由于高延时,延迟的变化,或无法响应ACK请求的慢速终端。

  1. 当重复ACK的数量保持在合理范围时,即12个百分比,则可能不是本机问题。
  2. 当有大量的重复ACK时(假设有10个),则可能:
  • 通信链路繁忙引起延迟改变
  • 服务器或客户端无响应

   3.  快速重传是对重复ACK的响应报文。

   4. 下图是该问题的示例。本例中51个重复ACK之后发生了快速重传:

image002.jpg

    5. 以下是如何解决该问题:

  • 如果重复ACK和重传数量较少(少于1个百分比),是可以接受的。
  • 如果重复ACK发生在无线网络环境,或是Internet之上的连接,延时或是延时的改变对于这类网络来说很常见,所以也没有什么可做的。
  • 如果发生在组织内的网络,则可能有问题。如果发生在LAN之上,检查严重的问题,例如缓存和CPU负载,慢速服务器,等等。如果发生在WAN之上,查看延时,负载以及线路不稳定。

工作原理

当发现有丢失报文时(期望的序列号没有收到),或者收到了预期之外的序列号。这种情况下,接收端生成一个ACK,声明自己希望收到的下一个序列号。接收方持续生成丢失片段的ACK请求,直到实际收到。

在发送方,当它收到三个相同的ACK(初始ACK和两个重复ACK),就会假设有报文丢失并重传该报文,无论重传计时器是否过期。再次发送的报文称为快速重传。

重复ACK也减少了发往网络的吞吐量。减少了多少吞吐量取决于TCP版本。比较早期的TCP版本中出现了重复ACK,发送方将吞吐量减少为之前的一半。在多个DupACK的情况下,吞吐量减到最小。

下图显示了重复ACK和重传的典型例子,本图中第一次重复ACK将吞吐量降低至大约40%,之后重传将吞吐量减至最小。

image003.jpg

乱序报文:

在两端抓包,乱序情况下需要关注三种现象:

  • 先前片段丢失:当前收到报文的序列号高于该连接的下一个期望序列号时,表明之前的一个或多个报文未能到达
  • 乱序报文:当前报文的序列号低于该连接先前收到的报文
  • 先前片段未能捕捉:(Wireshark 1.8.x及以上版本):同先前报文丢失。

何时发生?

用户可能在以下情况看到乱序报文:

  • 连接开始时抓包:当建立连接时抓包,这时,看到连接上的报文没有SYN/SYN-ACK/ACK,因此,Wireshark认为连接有问题。

  • 确实有报文丢失:这时会看到丢失报文重传和/或重复ACK告知发送方重传丢失报文。

image004.jpg

上图是报文丢失的典型示例。从图中可见,10.0.0.6尝试浏览站点62.90.90.210。这一过程中, TCP片段每个1420字节发送到web服务器,334336之间3个报文丢失,338340之间2个报文丢失。两者Wireshark都有提示:TCP’s previous segment is not captured.

  • 延时变化:这可能是由于报文从源地址到目的地址经由不同的路由。检查这一点可以使用Tracert,在源和目的地址之间查找路由改变。如果在公司内部网络上是可以做到的,例如,在路由器上配置trap

  • 数据捕捉问题:可能报文正常收发,但Wireshark没有捕捉到。可能有以下几种原因:
    • 数据量比较大时,Wireshark在高比特率的情况下可能会丢失报文(高于150-180 Mbps)。要避免这一问题,使用其他工具(大多数需要付费)。
    • 台式机不够强大,内存或CPU无法让Wireshark工作的足够快。这一点很好发现。
    • LAN交换机的端口缓存太小,报文可能被丢弃。连接到交换机(用控制台或telnet连接)使用交换机命令行来检查该问题。
    • 无线网络抓包,由于某种原因没有看到所有发送报文。

总结

乱序报文的原理很简单。TCP发送以其字节数为编号的报文到接收方。当一个报文没有按照顺序到达时,Wireshark就会注意到。原因有两点:

  • 确实有问题:这时会看到重传和重复ACK,这是TCP对于收到乱序报文的响应。
  • 抓包问题:这时仅看到乱序报文,但没有看到对可能丢失及乱序报文的响应,可能实际上并没有问题。

       

参考

Network Analysis Using Wireshark Cookbook

             

1.2K 消息

2015年2月9日 21:00

请留言,聊聊希望写点啥。

6 消息

2015年2月11日 17:00

楼主辛苦了,来支持一下,希望楼主能介绍下NAT的穿透(特别是tcp穿透NAT),网络拓扑结构的发现

1.2K 消息

2015年2月11日 18:00

谢谢支持。NAT已经写过一节,可能不会再写了~如有相关问题可以在帖里讨论~

1.2K 消息

2015年2月24日 23:00

网络基本功(二十六):Wireshark抓包实例分析TCP窗口及reset

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

TCP最重要的机制之一是滑动窗口机制,以及用以控制TCP终端节点愿意接收的数据总量的流控机制。

TCP reset可以在几种情况下被发送。有一些是协议的正常工作过程,有一些则表明可能有问题。本节中,我们查找问题以及分析解决问题的方法。

本章讨论以上两个问题。

更多信息

TCP窗口问题:

TCP零窗口,零窗口探测,零窗口违例

TCP零窗口发生于接收方在TCP头部的window字段广播接收窗口零字节的时候。这一事件告知发送方停止发送数据,因为接收方缓存已满。这也表明接收方可能发生以下问题:

  • 服务器无法为进程分配组后的内存
  • 应用碰到没有足够内存的问题,因此TCP需告知发送方停止发送数据
  • 应用消耗太多内存因此操作系统要限制应用资源

TCP零窗口探测由发送方发出,以查看接收方的零窗口是否依然存在。这一消息通过发送下一字节数据给接收方,如果接收方回复窗口大小仍然为零,则发送方的探测计时器加倍。

TCP窗口违例:发送方忽略接收方的零窗口大小并发送额外字节数据。TCP零窗口违例表明协议栈中有TCP错误。为了检查是何问题,检查是否有以下事件:

  • 某一终端设备(服务器或客户机)报出终端设备故障
  • 某一应用报出常规应用错误
  • 应用中执行某一操作时报错,例如,打开一个表格,发送一份文件至打印机,创建一个报告,或其他操作。这种情况下,是应用问题。

TCP窗口更新

TCP将窗口更新发送至连接的对端,以表明缓存大小更改,并且准备好接受更高或更低的数据速率(缓存大小决定了发送方被允许的发送速率)。这一情况发生于:

  • TCP接收方从零窗口中恢复,告知发送方重新发送速率。这一情况下,无需进行处理,只需检查第一次导致零窗口的问题。
  • TCP接收方频繁更改窗口大小。该情况下检查接收方被干扰的原因。可能是应用问题,内存问题,或终端设备上的其他问题。

看到这类现象无需担心,这就是TCP的工作机制。

TCP窗口已满

这一信息表明已发送的报文会完全填满接收方的接收缓存。发生于接收方没有对先前接收到的数据发出任何ACK确认信息,因此,这将会成为发送方从接收方收到ACK之前的最后一个报文数据。

这一事件的触发原因与触发零窗口的原因相同,是服务器或应用无响应的标志。典型实例如下图所示:

image002.jpg

上图中可以看到:

  1. 报文183816192.168.2.138告知192.168.1.58发送窗口已满。
  2. 下一个报文,192.168.1.58发送一个信号至192.168.2.138,告知对方停止发送数据。这是一个零窗口信号。
  3. 双方继续发送零窗口以及零窗口探测。
  4. 连接的最后一个报文是192.168.2.138发送的RST报文,目的是断开连接。
  5. 某些情况下零窗口可以通过窗口更改信息来回复。某些情况下可通过reset来关闭(可以是应用零窗口从而没有收到任何数据导致)。

工作原理

TCP滑动窗口机制如下:

  1. 连接建立之后,发送方将数据发送至接收方,填入接收窗口。
  2. 若干报文之后,接收方发送ACK至发送方,确认接收到其发送的字节数。发送ACK将接收窗口清零。
  3. 这一过程持续下去,发送方向窗口中填入数据,接收方清空并发送确认信息。
  4. 扩大接收窗口大小告知发送方增加吞吐量,减小窗口告知对方减小吞吐量。这一机制按照WS/RTT规则(随着TCP版本不同而有所改变):

image003.jpg

也可以通过TCP吞吐量图表和IO图来查看问题。在TCP吞吐量图表中,使用TCP trace图表,上面一行显示了窗口大小,与下面一行的距离表明窗口的剩余大小。没有距离表示零窗口。

image004.jpg

两行之间的固定距离表明接收方工作良好。当两行渐渐靠近,表明发送方速度高于接收方。只要这两行没有重叠,TCP就会继续发送数据。

TCP reset及原因:

在可疑的链路或服务器两端连接Wireshark,开始抓包。观察抓包窗口的每一个窗口信息。TCP reset可以在几种情况下被发送。有一些是协议的正常工作过程,有一些则表明可能有问题。本节中,我们查找问题以及分析解决问题的方法。

reset是用以告知接收方断开连接的TCP信号,通过将RST标志位置1来发送。正常的操作过程中,TCP通过SYN信号打开连接,通过FIN信号关闭连接。TCP的一大特性在于有问题时,或只是为了更好的性能,它能够快速关闭连接。

无故障时发送reset

TCP关闭连接的标准方式是通过FINFIN-ACK信号。为了关闭连接,用户需要四个报文:来自一方的FIN/ACKACK,以及另一方的同样报文。当你打开一个网页,可能同时打开了数十个连接(主页,新闻,广告,定期更新的图片等),要关闭所有这些有时需要数百个FINFIN-ACK报文。为了防止其发生,web服务器在很多情况下会在发送请求数据之后用reset断开连接。这是标准的做法,并取决于应用程序。

有故障时发送reset

某些情况下reset表明有故障发生(并不一定是通信故障):

  • 防火墙发送的reset:当远端服务器尝试打开连接但没有结果时,也许会看到返回RST信号。这是防火墙阻隔连接的情况。下图中,可看到发送的每一个SYN都返回以RST

image005.jpg

  • 由于收发一方有问题发送的reset:可能的原因如:
    • 五个连续没有收到ACK回复的重传。当发送方没有收到任何重传回复,它就会发送一个reset信号到对端,告知其断开连接。
    • 另一个原因是连接之上几分钟都没有任何数据(分钟数取决于系统默认)。打开连接的一方通常会发送reset(但并不总是会这样做,取决于实现方式)。

参考

Network Analysis Using Wireshark Cookbook

             

1.2K 消息

2015年3月9日 23:00

网络基本功(二十八):Wireshark抓包实例分析HTTP问题()

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

本文承接上文。


更多信息

Client errors:

                                                                         
 

Code

 
 

Status

 
 

Explanation

 
 

What    to do

 

400

Bad   request

The   request could not be understood by the server due to a syntax problem.   The request should be modified by the client before resending to it.

Check the   website address. This can also happen due to a site error.

401

Authorization   required

The   client is denied access due to the lack of authentication codes.

Check   your username and password.

402

Payment   required

Reserved   for future use.

403

Forbidden

The   client is not allowed to see a specific file. This can be due to the server   access limit.

Check the   credentials. Also, there are fewer chances that the server is loaded.

404

Not found

The   requested resource could not be found.

This can   be because the resource was deleted, or it never existed before. It can also   be due to URL misspellings.

405

Method   not allowed

The   method you are using to access the file is not supported or not allowed by   the resource.

406

Not   acceptable

Content   generated by the resource is not acceptable according to the client request.

Check/update   your browser.

407

Proxy   authentication required

Request   authentication is required before it can be performed.

The   client must first authenticate itself with the proxy.

408

Request   timed out

It took   the server longer than the allowed time to process the request.

Check   response time and load on the network.

409

Conflict

The   request submitted by the client cannot be completed because it   conflicts with some established rules.

Can be   because you try to upload a file that is older that the existing one or   similar problems. Check what the client is trying to do.

410

Gone

The URL   requested by the client is no longer available from that system.

Usually   this is a server problem. It can be due to a file that was deleted or   location was forwarded to a new location.

411

Content   length required

The   request is missing itsContent-Length header.

Compatibility   issue on a website. Change/update your browser.

412

Precondition   failed

The   client has not set up a configuration that is required for the file to be   delivered.

Compatibility   issue on a website. Change/update your browser.

413

Request   entity too long

The   requested file was too big to process.

Server   limitation.

414

Request   URI too long

The   address you entered was overly long for the server.

Server   limitation.

415

Unsupported   media type

The file   type of the request is not supported.

Server   limitation.

以下示例是一个简单的客户端报错。按照以下步骤进行操作:

  1. 右键有报错的报文。
  2. 选择Follow TCP stream,会看到以下窗口:

image002.jpg

   3.  显示以下内容:

Client errors:

                                 
 

Code

 
 

Status

 
 

Explanation

 
 

What    to do

 

500

Internal   server error

The web   server encountered an unexpected condition that prevented it from   carrying out the client request for access to the requested URL.

Response   that is usually caused by a problem in your Perl code when a CGI program is   run.

501

Not   implemented

The   request cannot be executed by the server.

A server   problem.

502

Bad   gateway

The   server you're trying to reach is sending back errors.

A server   problem.

503

Service   unavailable

The   service or file that is being requested is not currently available.

A server   problem.

504

Gateway   timeout

The   gateway has timed out. This message is like the 408 timeout   error, but this one occurs at the gateway of the server.

Server is   down or nonresponsive.

505

HTTP   version not supported

The HTTP   protocol version that you want to use for communicating with the server is   not supported by it.

Server   does not support the HTTP version.

服务器不可用(错误代码503)可能有多种原因。以下示例是一个小办公室碰到的问题:员工能够访问Facebook,但当他们点击站点上的链接,则显示页面被拦截。以下截屏中,可看出页面被防火墙拦截:

image003.jpg

工作原理:

标准的HTTP浏览模式如下:

  1. TCP打开连接(三路握手信号)
  2. HTTP发送GET命令
  3. 数据下载到浏览器

在一个网页打开多个连接的情况下(大多数网页都是如此)。每个连接需要一个DNS 查询,响应,TCP SYN-SYN/ACK-ACK,以及HTTP GET。之后数据才会出现在显示屏上。

当你在packet detail面板没有看到显示内容时,右键报文并选择Follow TCP stream,会看到连接的细节数据。另一个广泛应用的工具是FiddlerFiddlerHTTP故障排查的免费工具。

参考

Network Analysis Using Wireshark Cookbook

             

找不到事件!

Top