分类 "网络" 的存档.

三次握手的第三个ACK包丢了,TCP的处理方式

三次握手的第三个ACK包丢了——客户端认为连接建立,写数据时,会触发RST
当Client端收到Server的SYN+ACK应答后,其状态变为ESTABLISHED,并发送ACK包给Server;
如果此时ACK在网络中丢失,那么Server端该TCP连接的状态为SYN_RECV,并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包,以便Client重新发送ACK包。
Server重发SYN+ACK包的次数,可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改,默认值为5。 如果重发指定次数后,仍然未收到ACK应答,那么一段时间后,Server自动关闭这个连接。
但是Client认为这个连接已经建立,如果Client端向Server写数据,Server端将以RST包响应,方能感知到Server的错误.

curl使用via的header时,不支持gzip

curl -s -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-encoding: gzip,deflate' "http://m.news.haosou.com/" -H "Via: curl"  | gunzip -

使用这条命令去抓取页面, 不传递Via的header时,是能正常执行的,当带上via时,返回内容不再gzip,直接是正常文本。
查询了下相关资料,原来via参数在RFC里是有规范的,不是随便指定的。

见:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45


The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
The received-protocol indicates the protocol version of the message received by the server or client along each segment of the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded so that information about the protocol capabilities of upstream applications remains visible to all recipients.

The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol.

Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.

Comments MAY be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and MAY be removed by any recipient prior to forwarding the message.

For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Proxies and gateways used as a portal through a network firewall SHOULD NOT, by default, forward the names and ports of hosts within the firewall region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall SHOULD be replaced by an appropriate pseudonym for that host.

For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values.

使用 cURL 获取站点的各类响应时间 – dns解析时间,响应时间,传输时间

使用 cURL 获取站点的各类响应时间 – dns解析时间,响应时间,传输时间等:

curl -o /dev/null -s -w %{http_code}:%{http_connect}:%{content_type}:%{time_namelookup}:%{time_redirect}:%{time_pretransfer}:%{time_connect}:%{time_starttransfer}:%{time_total}:%{speed_download} digdeeply.org

这是一个本人博客站点执行 curl 命令的情况。输出通常是 HTML 代码,通过 -o 参数发送到 /dev/null。-s 参数去掉所有状态信息。-w 参数让 curl 输出的计时器的状态信息。

一次http请求中的各个时间段-dns解析,等待服务器响应,获取内容等

一次http请求中的各个时间段-dns解析,等待服务器响应,获取内容等

下边对-w参数做个详细的解释,由我(DigDeeply)翻译。有不对的地方请大家指出。(英文原文:http://curl.haxx.se/docs/manpage.html)

Read more…

IP和独立访客的区别?

IP: 指在一天之内(00:00-24:00)访问您的网站的独立IP数。一天内相同IP地址多次访问网站只被计算1次。

 独立访客: 指在一天之内(00:00-24:00)访问您的网站的上网电脑数量(以cookie为依据)。一天内同一电脑多次访问网站只被计算1次。

所以:

当独立访客高于IP数的时候正常是以下这种状况:一个局域网对外是相同的一个IP,但是有7个人同时访问,那么这个时候,独立访客为7,唯一IP仅为1。

当IP高于独立访客的时候正常是以下这种状况:一个用户,上网的时候频繁掉线,ADSL拔号7次均打开了此网站,此时,独立访客仅计为1,而IP数则被计为7。

Read more…

3070芯片和8187L芯片的对比

目前市场上出现了3070芯片,号称优点不少,那么,它和8187L对比,各有什么优点呢。

3070芯片和8187L芯片,如果是要用在蹭网卡上,还是RTL8187L的芯片更好.

1)RTL8187L的芯片对破解软件的兼容性几乎达到完美地步,雷凌3070芯片对破解软件的兼容性略差一点点.不过也不错.兼容性好意味破解成功率更高。

Read more…

华三 交换机 S3100 web页登陆设置

首先要通过console口设置访问IP,如下:

<H3C>sys
[H3C] interface Vlan-interface 1(进入管理VLAN)
[H3C-Vlan-interface1] undo ip address(取消管理VLAN原有的IP地址)
[H3C-Vlan-interface1] ip address 119.254.7.100 255.255.255.240(配置以太网交换机管理VLAN的IP地址为119.254.7.100,对应的掩码自己写好)

Read more…

为一个单网卡的XP系统设置两个或多个IP地址

网卡是一个物理设备,而不是一个逻辑设备。设置网卡地址则是一个逻辑地址,不是物理地址。
这样,一个网卡上面可以设置多个ip地址和网关。具体实施是这样的
打开网卡属性,最后一项有一个TCP/IP,点开他就可以了,那么现在你就能见到里面有设置IP地址,网络掩码和网关,下面还有DNS的设置。
最右边有一个高级,点开之后,里面可以设置第2、3个网卡的地址和多出来的DNS或者网关。

Read more…

什么是TRUNK?什么是端口汇聚?

  什么是Trunk? 什么是端口汇聚?

  TRUNK是端口汇聚的意思,就是通过配置软件的设置,将2个或多个物理端口组合在一起成为一条逻辑的路径从而增加在交换机和网络节点之间的带宽,将属于这几个端口的带宽合并,给端口提供一个几倍于独立端口的独享的高带宽。Trunk是一种封装技术,它是一条点到点的链路,链路的两端可以都是交换机,也可以是交换机和路由器,还可以是主机和交换机或路由器。基于端口汇聚(Trunk)功能,允许交换机与交换机、交换机与路由器、主机与交换机或路由器之间通过两个或多个端口并行连接同时传输以提供更高带宽、更大吞吐量, 大幅度提供整个网络能力。
Read more…