计算机网络总结

计算机网络从入门到熟悉

一起学习吧

七大层

自底向上
第一层：物理层：设备之间的数据通信提供传输媒体及互连设备，为数据传输提供可靠的环境；
第二层：数据链路层：将信号转化为数据然后交给网络层；
第三层：网络层：实现两个端系统之间的数据透明传送，具体功能包括寻址和路由选择、连接的建立、保持和终止等；
第四层：传输层：数据链路层和网络层一样,传输层的功能是保证数据可靠地从发送结点发送到目标结
第五层：会话层：主要功能是用来管理网络设备的会话连接
第六层：表示层：为在应用过程之间传送的信息提供表示方法的服务，它只关心信息发出的语法和语义。
第七层：应用层：提供网络任意终端上应用程序之间的接口。

以前年少无知的时候总觉得学习一些无用的专业课读不懂也没啥意思，现在回想起来，自己是什么胆子让自己这么想，以至于一个研究生能够基础差到不行，我觉得还是自己对自己不够严格。所幸的是自己学习能力和理解能力还行，所以要给自己一次接受新的自己，进步得机会。共勉。

物理层的梳理

本节由物理层描述而来

数据传输

我们的数据最后都是转换成01信号的，01信号又通过电流传播。但是这些信号如何在计算机中传递转换呢？因此需要对这些传输的信号进行分类，主要有两个：

1.传输信号分类：

（1）基带信号

像计算机输出的代表各种文字或图像文件的数据信号都属于基带信号。基带信号往往包含有较多的低频成分，甚至有直流成分，而许多信道并不能传输这种低频分量或直流分量。因此必须对基带信号进行调制。

（2）带通信号

把基带信号经过载波调制后，把信号的频率范围搬移到较高的频段以便在信道中传输。

2、如何调制信号

（1）调幅(AM)：载波的振幅随基带数字信号而变化。

（2）调频(FM)：载波的频率随基带数字信号而变化。

（3）调相(PM) ：载波的初始相位随基带数字信号而变化。

计算机网络总结
图片来自链接

3、信道的极限容量
既然是传输，肯定都会有一定的损耗，在传输信号时会产生各种失真以及带来多种干扰。而且码元传输的速率越高，或信号传输的距离越远，在信道的输出端的波形的失真就越严重。比如下面这种情况：

计算机网络总结
4、处理失真
（1）奈氏准则
（2）香农公式
三、信道复用技术
信道复用技术可以大大提升我们的传输能力和资源利用率。
1、频分复用 FDM
2、时分复用TDM
3、波分复用 WDM
4、码分复用 CDM
四、宽带接入
xDSL技术
xDSL 技术就是用数字技术对现有的模拟电话用户线进行改造，使它能够承载宽带业务。xDSL 技术就把 0~4 kHz 低端频谱留给传统电话使用，而把原来没有被利用的高端频谱留给用户上网使用。

其余的相关知识点参照

计算机网络常用知识点
 大佬的知识点

知识点总结

怎么实现强行关闭客户端和服务器的连接？

在socket通信过程中不算循环检测一个全局变量（开关标记变量），一旦标记变量变为关闭，则调用socket的close方法，循环结束，从而达到关闭连接的目的。

总而言之就是：调用closesocket

注意：Socket 编程就是-应用编程接口（没有学过的我，一脸懵逼）

简述TCP和UDP的区别以及优缺点

UDP和TCP：传输层的主要协议

UDP是面向无连接的通讯协议，UDP数据包括目的端口号和源端口号信息。

优点：

UDP速度快
操作简单
要求系统资源较少
由于通讯不需要连接，可以实现广播发送

缺点：

UDP传送数据前并不与对方建立连接
对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收
也不重复发送，不可靠。

TCP是面向连接的通讯协议，通过三次握手建立连接，通讯完成时四次挥手

优点：

TCP在数据传递时
有确认、窗口、重传、阻塞等控制机制
能保证数据正确性，较为可靠。

缺点：

TCP相对于UDP速度慢一点
要求系统资源较多。：

三次握手和四次挥手？

申明这是转发博主的链接，讲的明明白白

为什么要进行第三次握手

为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。
如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。
客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，
服务器端是不知道客户端有没有接收到服务器端返回的信息的。

面试官常问问题：

【问题】为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

【问题】什么是TCP的2MSL？

答：2MSL即两倍的MSL，TCP的TIME_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后,即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置 SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。

【问题】为什么客户端在TIME-WAIT状态必须等待2MSL的时间?

为了保证客户端发送的最后一个ACK报文段能够达到服务器。
这个ACK报文段可能丢失，因而使处在LAST-ACK状态的服务器收不到确认。服务器会超时重传FIN+ACK报文段，客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都正常进入到CLOSED状态。如果客户端在TIME-WAIT状态不等待一段时间，而是再发送完ACK报文后立即释放连接，那么就无法收到服务器重传的FIN+ACK报文段，因而也不会再发送一次确认报文。这样，服务器就无法按照正常步骤进入CLOSED状态。
防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个ACK确认报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

【问题】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

【问题】为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始***进行协商，这个***在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S是否已准备好，不知道S建立什么样的***，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

【问题】如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

传输层：网络层是主机与主机之间的通讯，而传输层则是进程之间的通讯。

为何要有传输层？
应为进程是资源分配的基本单位，计算机之间的信息传输也只是一台计算机的进程传输到另外一台计算机的进程中
一台计算机如何找到另外一台计算机呢？
那就是通过IP协议来完成的（复用，多个进程都可以把信息通过传输层到IP层，再传输到另外一台计算机中）。
那如何找到另外一台计算机的进程（pid）呢？
那就是用端口（分用，到达另外一台计算机后还要通过端口号找到对应进程）

【问题】为何TCP是可靠的呢？

其实TCP是依赖停止等待协议和连续ARQ 协议+滑动窗口协议才达到可靠的目的

. a.等待协议

特点：

资源利用率非常低工作原理
客户发送一次数据到服务端，必须等到服务端响应后才发第二次数据，中间的等待时间RTT占了大部分时间，中间如果出现差错（超时或确认丢失）都需要从新传输。

b.连续ARQ协议

连续ARQ协议工作原理

维持一个发送窗口（记录了当前可以发送的数据包数量n），在窗口内的数据都可以连续发送出去，服务器只在接收完一个发送窗口的数据后才回响应（累计确认），发送端接收到响应就把发送窗口移动n位，开始新一轮数据发送。
以上只是简单了解TCP协议的发送流程，如果要清楚发送细节，必须知道TCP报文首部

TCP报文段的首部格式
虽然说TCP是面向字节流的，但是TCP传输的数据单元却是报文段，报文段由首部和数据两部分组成，

计算机网络总结

HTTP协议

HTTP，即超文本传输协议，是一种实现客户端和服务器之间通信的响应协议，它是用作客户端和服务器之间的请求。

客户端（浏览器）会向服务器提交HTTP请求；然后服务器向客户端返回响应；其中响应包含有关请求的状态信息，还可能包含请求的内容。
应用层

特点：

支持客户端 / 服务器模式
简单快速
灵活
无连接，在完成一次请求获得响应后就会断开
无状态，没有记忆的，请求完一次后，就结束了，后面如果要再获得数据必须从新请求
请求报文的结构
请求头部：用于设置请求的的一些参数如：ContentType
请求空行：就算请求数据为空，都要有空行，表示请求首部的结束

HTTP请求方法都有什么？

HTTP请求的常用方法有：

GET方法
POST方法
HEAD方法
PUT方法
DELETE方法
CONNECT方法
OPTIONS方法
TRACE方法。

HTTP最常见的请求头

HTTP1.0 定义了三种请求方法： GET， POST 和 HEAD 方法。
HTTP1.1 新增了五种请求方法：OPTIONS， PUT， DELETE， TRACE 和 CONNECT 方法。
1、GET 请求指定的页面信息，并返回实体主体。
2、HEAD 类似于 get 请求，只不过返回的响应中没有具体的内容，用于获取报头
3、POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4、PUT 从客户端向服务器传送的数据取代指定的文档的内容。
5、DELETE 请求服务器删除指定的页面。
6、CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7、OPTIONS 允许客户端查看服务器的性能。
8、TRACE 回显服务器收到的请求，主要用于测试或诊断。

使用 Socket 套接字需要传入哪些参数？

Address Family 和 Type，分别表示套接字应用场景和类型。
family 的值可以是 AF_UNIX(Unix 域，用于同一台机器上的进程间通讯)，也可以是 AF_INET （对于 IPV4 协议的TCP 和 UDP），至于 type 参数，SOCK_STREAM（流套接字）或者
SOCK_DGRAM（数据报文套接字）,SOCK_RAW（raw 套接字）。

从浏览器地址栏键入URL，回车后会尽力的流程：

链接说的明明白白

DNS解析
TCP连接
发送HTTP请求
服务器处理请求，并返回HTTP报文
浏览器解析渲染页面
连接结束

GET请求与POST请求的区别

HTTP报文层面：GET请求信息放在URL中，POST放在报文体中
数据库层面：GET符合幂等性和安全性，POST不符合
其他层面：GET可以被缓存、储存，而POST不行

Cookie和Session的区别

为什么会有这两种技术？

在使用一些需要登录的网站时，每次访问，都会需要验证个人信息，即登录。这样做比较繁琐，能否将个人的账号和密码存起来，访问的时候直接用存取来的个人信息进行验证呢？解决这个问题的就是

Cookie和Session

Cookie：通过客户端（浏览器）来缓存个人信息。当用户第一次登录时，服务器会将个人信息放在了响应中，
浏览器接收到响应时候会将个人信息以Cookie的形式访问浏览器中保存起来，在下一次访问服务器的时候会带上该Cookie，Cookie中有个人信息，服务器能解析出来，所以不同再次登录验证了。（不够安全，对服务器的开销小）
Session通过服务端来缓存信息，根据请求中是否包含Session
id的字段，如果不存在则创建一个，并返回给浏览器缓存起来。如果存在则通过该Session
id在服务器存储中获得对应的Session信息，直接验证。（安全，服务器的开销变大）

HTTP与HTTPS的区别：

连接方式不同，HTTPS默认使用443端口，HTTP使用80端口
HTTPS = HTTP + 加密+认证+完整性保护，较HTTP安全
HTTPS需要到CA申请证书，HTTP不需要HTTPS密文传输、HTTP明文传输

其实也不一定就安全，原因是用户不会再访问时候加上http:// 或 https://,浏览器就默认会加上http://，然后通过转发的方式转成https:// 这个过程http就有可能会被劫持了。此时会用到一个技术 HSTS(HTTP Strict Transort Security)

HTTP版本有哪些特性

这里就废话不多说了，贴一个链接，说的非常详细http不同版本的特性
http的历史
http(超文本传输协议)，在创建之初就是为了将超文本标记语言（html）文档从web服务端传送给浏览器的客户端。随着我们网页内容变得复杂，不单单有文字、图片，还有css，js等等渲染，ajax的出现、移动互联网的高速发展，随着时代的变迁，http也一直升级优化，丰富自己的功能特性。

http的局限
其中带宽和延迟是影响http网络请求的两个重要的因素

带宽：

虽然我们还停留在拨号上网的阶段，但我们网络基建有着飞速的发展，2G、3G、4G、5G，带宽得到了极大的提升（虽然有时感觉还是达不到运营商承诺的那样，这是由于各个方面的复杂的原因决定了，但不否认网速的确提高了），我们对带宽的影响关注度小了。

延迟：

浏览器阻塞：为了提高众多用户的访问速度和解决阻塞问题，浏览器默认会对同一御下的资源只保持一定的连接数（这个连接数是由浏览器内核决定的）
DNS查询：dns系统需要实现域名、IP的转换，提高转换速度很重要（dns缓存的出现）
建立连接：http传输文件需要利用tcp的三次握手连接，这就会存在和三次握手一样的问题，建立连接需要经过多次确认消耗时间。

HTTP/0.9：

HTTP/0.9是第一个版本的HTTP协议，已过时。它的组成极其简单，只允许客户端发送GET这一种请求，且不支持请求头。由于没有协议头，造成了HTTP/0.9协议只支持一种内容，即纯文本。不过网页仍然支持用HTML语言格式化，同时无法插入图片。
HTTP/0.9具有典型的无状态性，每个事务独立进行处理，事务结束时就释放这个连接。由此可见，HTTP协议的无状态特点在其第一个版本0.9中已经成型。一次HTTP/0.9的传输首先要建立一个由客户端到web服务器的TCP连接，由客户端发起一个请求，然后由web服务器返回页面内容，然后连接会关闭。如果请求的页面不存在，也不会返回任何状态码。

http1.0：
最早在1996年在网页中使用，内容简单，所以浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。
HTTP协议的第二个版本，第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛使用。相对于HTTP/0.9增加了下面几个特性：

请求与响应支持头部。
响应对象以一个响应状态码开始。
响应对象不只限于超文本。
开始支持客户端通过POST方法向web服务器提交数据，支持GET、HEAD、POST方法。
支持长连接（但默认还是使用短连接）、缓存机制以及身份认证。

HTTP1.1：
到1999年广泛在各大浏览器网络请求中使用，HTTP/1.0中默认使用Connection: close。在HTTP/1.1中已经默认使用Connection: keep-alive（长连接），避免了连接建立和释放的开销，但服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。通过Content-Length字段来判断当前请求的数据是否已经全部接收。不允许同时存在两个并行的响应。
HTTP协议的第三个版本是HTTP/1.1，是目前使用最广泛的协议版本。HTTP/1.1是目前主流的HTTP协议版本，相对于HTTP/1.0新增了如下内容：

默认为长连接
-HTTP/1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP/1.1中默认开启Connection：keep-alive，一定程度上弥补了HTTP/1.0每次请求都要创建连接的缺点。
提供了范围请求功能（宽带优化）
在HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP/1.1则在请求头引入了range头域，它允许值请求资源的某个部分，即返回码是2.6（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。这是支持文件断点续传的基础。
提供了虚拟主机的功能（HOST域）
在HTTP/1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，每一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP/1.1请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400Bad Request）。
缓存处理字段
HTTP/1.1在1.0的基础上加入了一些cache的新特性，引入了实体标签，一般被称为e-tags，新增更为强大的Cache-Control头。
错误通知的管理
在HTTP/1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

HTTP2.0：
HTTP/2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，（流（stream）：已建立连接上的双向字节流；消息：与逻辑消息对应的完整的一系列数据帧；帧：HTTP2.0通信的最小单位，每个帧包含帧头部，至少也会标识出当前帧所属的流（stream id））这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况。同样是因为有了序列，服务器就可以并行的传输数据，这就是流所做的事情。这些数据帧都在一个tcp连接（可以承载任意数量的双向数据流）上并行发送。
HTTP协议的第四个版本，相对于HTTP/1.1新增了以下内容：

二进制分帧，HTTP/2.0的所有帧都采用二进制编码。
帧：客户端与服务器通过交换帧来通信，帧是基于这个新协议通信的最小单位。消息：指逻辑上的HTTP消息，比如请求、响应等，由一或多个帧组成。
流：流是连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1，2…N）。
多路复用
多路复用允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。有了新的分帧机制后，HTTP/2.0不再依赖多个TCP连接去处理更多并发的请求。每个数据流都拆分成很多互不依赖的帧，而这些帧可以交错（乱序发送），还可以分优先级。最后再在另一端根据每个帧首部的流标识符把它们重新组合起来。HTTP/2.0连接都是持久化的，而且客户端与服务器之间也只需要一个连接（每个域名一个连接）即可。
头部压缩
HTTP/1.1的首部带有大量信息，而且每次都要重复发送。HTTP/2.0要求通讯双方各自缓存一份首部字段表，从而避免了重复传输。
请求优先级
浏览器可以在发现资源时立即分派请求，指定每个流的优先级，让服务器决定最优的响应次序。这样请求就不必排队了，既节省了时间，也最大限度地利用了每个连接。
服务端推送
服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。

http1.0和http1.1的主要区别如下：

1、缓存处理：1.1添加更多的缓存控制策略（如：Entity tag，If-Match）
2、网络连接的优化：1.1支持断点续传
3、错误状态码的增多：1.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态
4、Host头处理：支持Host头域，不在以IP为请求方标志
5、长连接：减少了建立和关闭连接的消耗和延迟。

http1.1和http2.0的主要区别：

1、新的传输格式：2.0使用二进制格式，1.0依然使用基于文本格式
2、多路复用：连接共享，不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）
3、header压缩：由于1.X中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的hearder大小
4、服务端推送：同google的SPDUY（1.0的一种升级）一样

列出你知道的HTTP协议的状态码说出表示什么意思

200 - 服务器成功返回网页
404 - 请求的网页不存在
503 - 服务器超时

简述浏览器通过 WSGI 请求动态资源的过程?

发送 http 请求动态资源给 web 服务器
web 服务器收到请求后通过 WSGI 调用一个属性给应用程序框架
应用程序框架通过引用 WSGI 调用 web 服务器的方法，设置返回的状态和头信息。
调用后返回，此时 web 服务器保存了刚刚设置的信息
应用程序框架查询数据库，生成动态页面的 body 的信息
把生成的 body 信息返回给 web 服务器 7.web 服务器吧数据返回给浏览器

描述用浏览器访问 www.baidu.com 的过程

浏览器获取输入的域名www.baidu.com
浏览器向DNS请求解析www.baidu.com的IP地址
域名系统DNS解析出百度服务器的IP地址（详细介绍DNS）-通过网关出去
浏览器与该服务器建立TCP连接(默认端口号80)
浏览器发出HTTP请求，请求百度首页
服务器通过HTTP响应把首页文件发送给浏览器
TCP连接释放
浏览器将首页文件进行解析，并将Web页显示给用户。

URL的形式

形式 scheme://host[:port#]/path/…/[?query-string][#anchor]

scheme:协议（例如：http,https,ftp）
host:服务器的IP地址或者域名
port:服务器的端口（如果是走协议默认端口，80 or 443）
path:访问资源的路径
query-string:参数，发送给http服务器的数据
anchor:锚（跳转到网页指定锚点位置）

好啦，这是我今天总结的知识点，希望我的努力配得上我的梦想。