计算机网络基础概念
参考的博客：http://blog.csdn.net/shadowkiss/article/details/6552144
1、三类IP地址：
1）A类IP地址
一个A类IP地址由1字节的网络地址和3字节主机地址组成，网络地址的最高位必须是“0”， 可用的A类网络有126个，每个网络能容纳1亿多个主机。
2）B类IP地址
一个B类IP地址由2个字节的网络地址和2个字节的主机地址组成，网络地址的最高位必须是“10”，地址范围从128.0.0.0到191.255.255.255。可用的B类网络有16382个，每个网络能容纳6万多个主机 。
172.16.0.0到172.31.255.255是私有地址
169.254.0.0到169.254.255.255是保留地址
3）C类IP地址
一个C类IP地址由3字节的网络地址和1字节的主机地址组成，网络地址的最高位必须是“110”。范围从192.0.0.0到223.255.255.255。C类网络可达209万余个，每个网络能容纳254个主机。
C类地址中的私有地址：192.168.0.0到192.168.255.255是私有地址。
2、子网掩码
两级IP地址：前16位表示网络号，后16位表示主机号
三级IP地址：前16位表示网络号，接下来8位表示子网号，最后8位表示主机号
3、ARP是地址解析协议，将IP地址映射到硬件地址；RARP是逆地址解析协议，将自己硬件地址映射到IP地址上。
4、TCP协议的三次握手过程：
发送端发送一个SYN=1，ACK=0，SEQ=x标志的数据包给接收端，请求进行连接，这是第一次握手；接收端收到请求并且允许连接的话，就会发送一个SYN=1，ACK=1,SEQ=y标志的数据包给发送端，告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；最后，发送端发送一个SYN=0，ACK=1的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之后，一个TCP连接建立，开始通讯。（SYN是同步比特，置为1就表示这是一个连接请求或连接接受报文）
//可以参考“计算机网络”的第249页，还有TCP协议的四次挥手过程，其中当客户端发送FIN=1的报文时，等待着确认ACK的到达，这时状态为FIN_WAIT_1;
当客户端收到ACK时，则一个方向的连接关闭了，状态为FIN_WAIT_2;当客户端收到服务端发送的FIN=1时，应该响应确认的ACK，这时另一条连接也关闭了。但是TCP还要等待一段时间，此时间是2倍的MSL（最大分节生命期），TCP才能删除原来建立的连接记录，返回CLOSED状态。这么做是为了保证原来连接上面的所有分组都从网络中消失，可靠地实现TCP全双工连接的终止。
【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
5、物理层和数据链路层的作用：（很容易颠倒）
UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。
TCP协议传输速度慢，UDP协议传输速度快
TCP协议保证数据顺序，UDP协议不保证
TCP协议保证数据正确性，UDP协议可能丢包
TCP协议对系统资源要求多，UDP协议要求少
7、网络中常用的结构
1）星型结构：
动态路由：是网络中的路由器之间相互通信，传递路由信息，利用收到的路由信息更新路由器表的过程。它能实时地适应网络结构的变化。如果路由更新信息表明发生了网络变化，路由选择软件就会重新计算路由，并发出新的路由更新信息。这些信息通过各个网络，引起各路由器重新启动其路由算法，并更新各自的路由表以动态地反映网络拓扑变化。动态路由适用于网络规模大、网络拓扑复杂的网络。
1）TCP协议：
对于客户端，要主动连接服务器的IP和指定端口。
对于服务器，要绑定监听的地址和端口。服务器可能有多块网卡，可以绑定到某一块网卡的IP地址上，也可以用0.0.0.0绑定到所有的网络地址，还可以用127.0.0.1绑定到本机地址。127.0.0.1是一个特殊的IP地址，表示本机地址，如果绑定到这个地址，客户端必须同时在本机运行才能连接，也就是说，外部的计算机无法连接进来。然后，对每一个新的连接，创建一个线程或进程来处理。通常，服务器程序会无限运行下去。同一个端口，被一个Socket绑定了以后，就不能被别的Socket绑定了。一个Socket依赖4项：服务器地址、服务器端口、客户端地址、客户端端口来唯一确定一个Socket。
2）UDP协议：
UDP的使用与TCP类似，但是不需要建立连接。此外，服务器绑定UDP端口和TCP端口互不冲突，也就是说，UDP的9999端口与TCP的9999端口可以各自绑定。
服务器：创建Socket时，SOCK_DGRAM指定了这个Socket的类型是UDP。绑定端口和TCP一样，但是不需要调用listen()方法，而是直接接收来自任何客户端的数据。
客户端：使用UDP时，首先仍然创建基于UDP的Socket，然后，不需要调用connect()，直接通过sendto()给服务器发数据。
socket的几个关键函数分析：socket;connect;recv;send;bind;listen;accept
10、TCP和UDP报文格式
TCP如下：源端口与目的端口都是2个字节：
对TCP报头的解释：
●源、目标端口号字段：占16比特。TCP协议通过使用"端口"来标识源端和目标端的应用进程。端口号可以使用0到65535之间的任何数字。在收到服务请求时，操作系 统动态地为客户端的应用程序分配端口号。在服务器端，每种服务在"众所周知的端口"（Well-Know Port）为用户提供服务。
●顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。
●确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。
●头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部。
●标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下：
◆URG：紧急指针（urgent pointer）有效。
◆ACK：确认序号有效。
◆PSH：接收方应该尽快将这个报文段交给应用层。
◆RST：重建连接。
◆SYN：发起一个连接。
◆FIN：释放一个连接。
●窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机期望一次接收的字节数。
●TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
●紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
●选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项。
UDP报文格式：由四个字段组成，每个字段都是两个字节
11、Http协议相关知识：
http://blog.csdn.net/zhll3377/article/details/7748086
http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html
http://www.blogjava.net/zjusuyong/articles/304788.html
Http的请求报文结构如下：
Http的响应报文结构如下：
Http响应状态码：
1xx(临时响应)
用于表示临时响应并需要请求者执行操作才能继续的状态代码。
代码 说明
100(继续) 请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。
101(切换协议) 请求者已要求服务器切换协议，服务器已确认并准备进行切换。
2xx(成功)
用于表示服务器已成功处理了请求的状态代码。
代码 说明
200(成功) 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。如果您的 robots.txt文件显示为此状态，那么，这表示 Googlebot 已成功检索到该文件。
201(已创建) 请求成功且服务器已创建了新的资源。
202(已接受) 服务器已接受了请求，但尚未对其进行处理。
203(非授权信息) 服务器已成功处理了请求，但返回了可能来自另一来源的信息。
204(无内容) 服务器成功处理了请求，但未返回任何内容。
205(重置内容) 服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图(例如清除表单内容以输入新内容)。
206(部分内容) 服务器成功处理了部分 GET 请求。
3xx(已重定向)
要完成请求，您需要进一步进行操作。通常，这些状态代码是永远重定向的。Google 建议您在每次请求时使用的重定向要少于 5 个。您可以使用网站管理员工具来查看 Googlebot 在抓取您已重定向的网页时是否会遇到问题。诊断下的抓取错误页中列出了 Googlebot 由于重定向错误而无法抓取的网址。
代码 说明
300(多种选择) 服务器根据请求可执行多种操作。服务器可根据请求者 (User agent) 来选择一项操作，或提供操作列表供请求者选择。
301(永久移动) 请求的网页已被永久移动到新位置。服务器返回此响应(作为对 GET 或 HEAD 请求的响应)时，会自动将请求者转到新位置。您应使用此代码通知 Googlebot 某个网页或网站已被永久移动到新位置。
302(临时移动) 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。
303(查看其他位置) 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。
304(未修改) 自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。
网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应(称为 If-Modified-Since HTTP 标头)。由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过，因此可节省带宽和开销。
305(使用代理) 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
307(临时重定向) 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。
4xx(请求错误)
这些状态代码表示，请求可能出错，已妨碍了服务器对请求的处理。
代码 说明
400(错误请求) 服务器不理解请求的语法。
401(未授权) 请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。
403(已禁止) 服务器拒绝请求。如果在 Googlebot 尝试抓取您网站上的有效网页时显示此状态代码(您可在 Google 网站管理员工具中诊断下的网络抓取页面上看到此状态代码)，那么，这可能是您的服务器或主机拒绝 Googlebot 对其进行访问。
404(未找到) 服务器找不到请求的网页。例如，如果请求是针对服务器上不存在的网页进行的，那么，服务器通常会返回此代码。
如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具"诊断"标签的 robots.txt 页上发现此状态，那么，这是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。(该文件应当位于顶级域名上，且应当名为 robots.txt)。
如果您在 Googlebot 尝试抓取的网址上发现此状态(位于"诊断"标签的 HTTP 错误页上)，那么，这表示 Googlebot 所追踪的可能是另一网页中的无效链接(旧链接或输入有误的链接)。
405(方法禁用) 禁用请求中所指定的方法。
406(不接受) 无法使用请求的内容特性来响应请求的网页。
407(需要代理授权) 此状态代码与 401(未授权)类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
408(请求超时) 服务器等候请求时超时。
409(冲突) 服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。
410(已删除) 如果请求的资源已被永久删除，那么，服务器会返回此响应。该代码与 404(未找到)代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已被永久删除，那么，您应当使用 301 代码指定该资源的新位置。
411(需要有效长度) 服务器不会接受包含无效内容长度标头字段的请求。
412(未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。
413(请求实体过大) 服务器无法处理请求，因为请求实体过大，已超出服务器的处理能力。
414(请求的 URI 过长) 请求的 URI(通常为网址)过长，服务器无法进行处理。
415(不支持的媒体类型) 请求的格式不受请求页面的支持。
416(请求范围不符合要求) 如果请求是针对网页的无效范围进行的，那么，服务器会返回此状态代码。
417(未满足期望值) 服务器未满足"期望"请求标头字段的要求。
5xx(服务器错误)
这些状态代码表示，服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。
代码 说明
500(服务器内部错误) 服务器遇到错误，无法完成请求。
501(尚未实施) 服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。
502(错误网关) 服务器作为网关或代理，从上游服务器收到了无效的响应。
503(服务不可用) 目前无法使用服务器(由于超载或进行停机维护)。通常，这只是一种暂时的状态。
504(网关超时) 服务器作为网关或代理，未及时从上游服务器接收请求。
505(HTTP 版本不受支持) 服务器不支持请求中所使用的 HTTP 协议版本。
1、GET请求，请求的数据会附加在URL之后，以?分割URL和传输数据，多个参数用&连接。
POST请求：POST请求会把请求的数据放置在HTTP请求包的包体中。
因此，GET请求的数据会暴露在地址栏中，而POST请求则不会。
2、传输数据的大小
在实际开发过程中，对于GET，特定的浏览器和服务器对URL的长度有限制。因此，在使用GET请求时，传输数据会受到URL长度的限制。
对于POST，由于不是URL传值，理论上是不会受限制的，但是实际上各个服务器会规定对POST提交数据大小进行限制，Apache、IIS都有各自的配置。
3、安全性
POST的安全性比GET的高。这里的安全是指真正的安全，而不同于上面GET提到的安全方法中的安全，上面提到的安全仅仅是不修改服务器的数据。比如，在进行登录操作，通过GET请求，用户名和密码都会暴露再URL上，因为登录页面有可能被浏览器缓存以及其他人查看浏览器的历史记录的原因，此时的用户名和密码就很容易被他人拿到了。
Http的请求方法有：
Head,Get------read
Put-------------create
Post------------update
Delete---------delete
Options-------options
trace----------基本不用
Cookie与Session的作用原理：
2. 思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
3. Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。
Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。
Http1.0与Http1.1的区别：
1：建立连接
在HTTP1.0中，每对Request/Response都使用一个新的连接。
而HTTP 1.1则支持Persistent Connection, 并且默认使用persistent connection，减少了建立和关闭连接的消耗和延迟。
2：增加请求头的信息
HTTP1.1在Request消息头里头多了一个Host域 以及Cache处理。
3：增加请求方法
HTTP1.1增加了OPTIONS, PUT, DELETE, TRACE, CONNECT这些Request方法.
4：增加状态响应
使得响应码更加的具体
Http怎么处理长连接？其中的长连接就是HTTP1.0中的Connect:keep alive以及HTTP1.1中的Persistent Connection.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份.
4.http的连接很简单,是无状态的
5.https协议是由ssl+http协议构建的可进行加密传输、身份认证的网络协议要比http协议安全
12、TCP拥塞控制
参考的网址：http://blog.csdn.net/sicofield/article/details/9708383
慢开始与拥塞避免：
主要介绍了慢开始（指数增长），到了ssthresh(慢开始门限)，就要考虑使用拥塞避免进行线性增长，当出现网络拥塞时，将窗口大小改为1，
将ssthresh改为出现拥塞时窗口大小的一半。
快重传与快恢复：
快重传：发送端只要一接收到三个重复的ACK即可判定有分组丢失了，就应该立即重传丢失的报文段，而不应该继续等待为其设置的重传计时器的超时。
13、TCP流量控制与滑动窗口（回退N帧协议）
http://www.cnblogs.com/woaiyy/p/3554182.html
14、DNS的介绍以及它所采用的传输协议
DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议；
一：DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。
Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
if the window size >= MSS and available data is >= MSS send complete MSS segment now else if there is unconfirmed data still in the pipe enqueue data in the buffer until an acknowledge is received else send data immediately end if end if end if 
