1、bin目录

hadoop：hadoop shell

hadoop-config.sh  给hadoop的一些变量赋值 HADOOP_HOME、HADOOP_CONF等

hadoop-deamon.sh

call salves.sh

start-all.sh

start-dfs sh

start-balancer sh

start-jobhistoryserver sh

start-mapred.sh

其他的还是参考ppt吧，

hadoop namenode –format 格式化 类似于格式化磁盘

hadoop fsck

hadoop diskcp  “hdfs://localhost:9000/tmp/test” “hdfs://localhost:9000/tmp/test2”  (会启动mapreduce) 虚拟机比较慢。。 集群直接复制，hadoop版本必须一致。

hadoop classpath  查看依赖的jar包 

hadoop deamonlog  -getlevel localhost:50070 namenode 看日志级别

hadoop deamonlog  -setlevel localhost:50070 namenode info 设置日志级别

HTTP/1.1 默认的连接方式是长连接，不能通过简单的TCP连接关闭判断HttpMessage的结束。以下是几种判断HttpMessage结束的方式：

1.      HTTP协议约定status code 为1xx，204，304的应答消息不能包含消息体（Message Body）, 直接忽略掉消息实体内容。[适用于应答消息]

Http Message =Http Header

2.      如果请求消息的Method为HEAD，则直接忽略其消息体。[适用于请求消息]

Http Message =Http Header

3.      如果Http消息头部有“Transfer-Encoding:chunked”，则通过chunk size判断长度。

4.      如果Http消息头部有Content-Length且没有Transfer-Encoding（如果同时有Content-Length和Transfer-Encoding,则忽略Content-Length），则通过Content-Length判断消息体长度。

5.      如果采用短连接（Http Message头部Connection:close），则直接可以通过服务器关闭连接来确定消息的传输长度。[适用于应答消息，Http请求消息不能以这种方式确定长度]

6.      还可以通过接收消息超时判断，但是不可靠。Python Proxy实现的http代理服务器用到了超时机制，源码地址见References[7]，仅100多行。

HTTP协议规范RFC 2616的4.4 Message Length中对相关内容有较多的描述(https://tools.ietf.org/html/rfc2616#section-4.4)。

一个实例，Python标准库httplib.py源码解读（http协议客户端的实现）

import httplib
conn = httplib.HTTPConnection("google.com")
conn.request('GET', '/')
print conn.getresponse().read()
conn.close()

但是一般不直接使用httplib,而是使用更高层的封装urllib,urllib2

conn = httplib.HTTPConnection("google.com")创建HTTPConnection对象，指定要请求的webserver.

conn.request('GET', '/')向google.com发送http请求，Method为GET

conn.getresponse()创建HTTPResponse对象，接收并读取http应答消息头，read()读取应答消息体。

函数调用关系:

       getresponse()->[创建HTTPResponse对象response]-> response.begin()->response.read()

重点是begin()和read()，begin() 完成了4件事：

       (1)创建HTTPMessage对象并解析Http应答消息的头部。

       (2)查看头部是否有“Transfer-Encoding:chunked”。

       (3)查看接收完应答消息后是否关闭TCP连接(调用_check_close())。

       (4)如果头部有“Content-Length”并且没有“Transfer-Encoding:chunked”，则获取消息体长度。

          _check_close()判断若Http应答消息头部有“Connection:close”则接收完应答消息后关闭TCP连接，同时还有一些向后兼容HTTP/1.0的代码。HTTP/1.1默认是“Connection:Keep-Alive”，即使头部中没有。

          read()根据Content-Length或chunked分块方式读取Http应答消息体，可一次全部读取也可以指定要读取的字节数。如果是chunked方式，调用_read_chunked()读取。

       _read_chunked()根据chunksize读取chunks,当读取完最后一个chunk(最后一个chunk的chunksize = 0)后就完成了Http应答消息的接收。相关的HTTP协议规范参考RFC2616 3.6.1，RFC2616 19.4.6

length:= 0
readchunk-size, chunk-extension (if any) and CRLF
while(chunk-size > 0) {
    read chunk-data and CRLF
    append chunk-data to entity-body
    length := length + chunk-size
    read chunk-size and CRLF
}
readentity-header
while(entity-header not empty) {
    append entity-header to existing headerfields
    read entity-header
}
Content-Length:= length
Remove"chunked" from Transfer-Encoding

来看一下begin()，_check_close()，read()，_read_chunked()的主要代码：

 def begin(self):
		......
        self.msg = HTTPMessage(self.fp, 0)
        # don't let the msg keep an fp
        self.msg.fp = None

        # are we using the chunked-style of transfer encoding?
        tr_enc = self.msg.getheader('transfer-encoding')
        if tr_enc and tr_enc.lower() == "chunked":
            self.chunked = 1
            self.chunk_left = None
        else:
            self.chunked = 0

        # will the connection close at the end of the response?
        self.will_close = self._check_close()

        # do we have a Content-Length?
        # NOTE: RFC 2616, S4.4, #3 says we ignore this if tr_enc is "chunked"      

      
      
    

      

        ICMP的全称是 Internet Control Message Protocol ,它是TCP/IP协议族的一个子协议，属于网络层协议，用于在IP主机、路由器之间传递控制消息。从技术角度来讲，就是让我们能够判断网络通不通、主机是否可达、路由是否可用等等。

        在网络中，ICMP协议的应用随处可见，比如我们经常使用的用于检查网络通不通的Ping命令，这个“Ping”的过程实际上就是ICMP协议工作的过程。那么当你“Ping”时，具体的ICMP协议是怎么工作的呢？

Ping命令

        Ping命令利用ICMP回射请求报文和回射应答报文来测试目标系统是否可达。ICMP回射请求和ICMP回射应答报文是配合工作的｡当源主机向目标主机发送了ICMP回射请求数据包后,它期待着目标主机的回答｡目标主机在收到一个ICMP回射请求数据包后,它会交换源､目的主机的地址,然后将收到的ICMP回射请求数据包中的数据部分原封不动地封装在自己的ICMP回射应答数据包中,然后发回给发送ICMP回射请求的一方｡如果校验正确,发送者便认为目标主机的回射服务正常,也即物理连接畅通｡如果校验错误，源主机随后可根据ICMP报文确定发生错误的类型，并确定如何才能更好地重发失败的数据包。注意，ICMP唯一的功能是报告问题而不是纠正错误，纠正错误的任务由源主机完成。

ICMP 重定向

        ICMP虽然不是路由协议,但是有时它也可以指导数据包的流向(使数据流向正确的网关)｡ICMP协议通过ICMP重定向数据包达到这个目的｡

参考文章:ICMP协议Ping命令的应用

感谢关注！

更多信息与我们交流：

WIZnet邮箱：wiznetbj@wiznet.co.kr

WIZnet中文主页：http://www.iwiznet.cn

WIZnet企业微博：http://e.weibo.com/wiznet2012