计算机网络 知识点小结3

部分转载自:
https://www.cnblogs.com/wqhwe/p/5407468.html
http://blog.csdn.net/a19881029/article/details/14002273
https://www.cnblogs.com/sjm19910902/p/6423181.html
http://blog.csdn.net/wuhuagu_wuhuaguo/article/details/78552633
https://segmentfault.com/q/1010000007715137/a-1020000007716965
https://www.cnblogs.com/gamir/p/4307849.html
http://blog.csdn.net/bingjing12345/article/details/9819731
http://www.cnblogs.com/0201zcr/p/4694945.html

1、URL

以下关于URL的叙述中,不正确的是:(A)
A.使用www.abc.com和abc.com打开的是同一页面
B.在地址栏中输入www.abc.com默认使用http协议
C.www.abc.com中的“www”是主机名
D.www.abc.com中的“abc.com”是域名

URL由三部分组成:
资源类型、存放资源的主机域名、资源文件名
URL的一般语法格式为:
protocol://hostname[:port]/path/filename

protocol指定使用的传输协议,最常见的是HTTP或HTTPS协议,也可以是其他协议如file、ftp、gopher、mms、ed2k等;
hostname是指主机名,即存放资源的服务域名 或者IP地址;
port指各种传输协议所使用的默认端口号,该选项是可选选项,例如http的默认端口号为80,一般可以省略,若出于安全考虑,可以更改默认的端口号,这时该选项必选;
path是指路径,有一个或多个/分隔,一般用来表示主机上的一个目录或者文件地址;
filename是指文件名,用于指定需要打开的文件名称。

一般情况下,一个URL可以采用“主机名.域名”的形式打开指定页面,也可以单独使用“域名”来打开,但前提是需进行相应的设置和对应。


2、HTTP与HTTPS有什么区别?

  HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全,通过抓包工具可以分析其信息内容。为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。

简单来说,HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全。

HTTP缺点:

a、通信使用明文不加密,内容可能被窃听
b、不验证通信方身份,可能遭到伪装
c、无法验证报文完整性,可能被篡改

HTTPS就是HTTP加上加密处理(一般是SSL安全通信线路)+认证+完整性保护

HTTPS和HTTP的区别主要如下:
  1、https协议需要到CA申请证书,一般免费证书较少,因而需要一定费用。
  2、http是超文本传输协议,信息是明文传输,https则是具有安全性的SSL加密传输协议
  3、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443
  4、http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。

HTTPS缺省工作在TCP协议443端口,
它的工作流程一般如以下方式:
1) 完成TCP三次同步握手
2) 客户端验证服务器数字证书,通过,进入步骤3
3) DH算法协商对称加密算法的密钥、hash算法的密钥
4) SSL安全加密隧道协商完成
5)网页以加密的方式传输,用协商的对称加密算法和密钥加密,保证数据机密性;用协商的hash算法进行数据完整性保护,保证数据不被篡改

如果HTTPS是网银服务,以上SSL安全隧道成功建立才会要求用户输入账户信息,账户信息是在安全隧道里传输,不会泄密。


3、几个命令:ping.netstat.arp.tracert

ping命令:判断用户与外部站点的连通性。
1)ping127.0.0.1(本地循环地址),无法ping则说明本机TCP/IP协议不能正常工作
2)ping+本机IP不通则说明网络适配器(网卡/MODEM)出现故障
3)ping+同一网段计算机的IP不通则说明网络线路出现故障;

netstat命令:用于显示TCP、UDP、IP、ICMP协议相关统计数据,一般用于检验本机网络端口的连接情况

ARP命令:可以查看和修改本地计算机的ARP表项,和查看ARP缓存和解决地址解析问题非常使用。

Tracert命令:可以跟踪网络连接,Tracert(路由跟踪)是路由跟踪程序,用于确定IP数据报访问目标所采取的路径,可以查看哪段路由出现连接问题


4、常见的HTTP方法?

GET:从指定的资源请求数据。
用于请求访问已经被URI(统一资源标识符)识别的资源,可以通过URL传参给服务器。
这里写图片描述

POST:向指定的资源提交要被处理的数据。
用于传输信息给服务器,主要功能与GET方法类似,但一般推荐使用POST方式。
这里写图片描述
这里写图片描述


5、GET方法与POST方法的区别

这里写图片描述

注:URI、URL和URN之间的区别:

URI全名为Uniform Resource Indentifier(统一资源标识),用来唯一的标识一个资源,是一个通用的概念,URI由两个主要的子集URL和URN组成

URL全名为Uniform Resource Locator(统一资源定位),通过描述资源的位置来标识资源
URN全名为Uniform Resource Name(统一资源命名),通过资源的名字来标识资源,与其所处的位置无关,这样即使资源的位置发生变动,其URN也不会变化

HTTP规范将更通用的概念URI作为其资源标识符,但是实际上,HTTP应用程序处理的只是URI的URL子集


6、HTTP请求报文与响应报文格式

请求报文包含三部分:请求行、请求头部、请求正文
这里写图片描述

1)请求行

由3部分组成,分别为:请求方法、URL以及协议版本,之间由空格分隔

请求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及扩展方法,当然并不是所有的服务器都实现了所有的方法,部分方法即便支持,处于安全性的考虑也是不可用的

协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1

2)请求头部

请求头部为请求报文添加了一些附加信息,由“名/值”对组成,每行一对,名和值之间使用冒号分隔

常见请求头如下:

请求头说明
Host接受请求的服务器地址,可以是IP:端口号,也可以是域名
User-Agent发送请求的应用程序名称
Connection指定与连接相关的属性,如Connection:Keep-Alive
Accept-Charset通知服务端可以发送的编码格式
Accept-Encoding通知服务端可以发送的数据压缩格式
Accept-Language通知服务端可以发送的语言

请求头部的最后会有一个空行,表示请求头部结束,接下来为请求正文,这一行非常重要,必不可少

3)请求正文

可选部分,比如GET请求就没有请求正文

GET请求示例:
这里写图片描述

POST请求示例:
这里写图片描述

响应报文包含三部分:状态行、响应头部、响应正文

这里写图片描述

1)状态行

由3部分组成,分别为:协议版本,状态码,状态码描述,之间由空格分隔

状态行格式如下:
HTTP-Version Status-Code Reason-Phrase CRLF
其中,HTTP-Version表示服务器HTTP协议的版本;
Status-Code表示服务器发回的响应状态代码;
Reason-Phrase表示状态代码的文本描述
举个例子:HTTP/1.1 200 OK(CRLF)。

状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值

1xx:指示信息--表示请求已接收,继续处理。
2xx:成功--表示请求已被成功接收、理解、接受。
3xx:重定向--要完成请求必须进行更进一步的操作。
4xx:客户端错误--请求有语法错误或请求无法实现。
5xx:服务器端错误--服务器未能实现合法的请求。

这里列举几个常见的:

200 OK:客户端请求成功。
400 Bad Request:客户端请求有语法错误,不能被服务器所理解。
401 Unauthorized:请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用。
403 Forbidden:服务器收到请求,但是拒绝提供服务。
404 Not Found:请求资源不存在,举个例子:输入了错误的URL。
500 Internal Server Error:服务器发生不可预期的错误。
503 Server Unavailable:服务器当前不能处理客户端的请求,一段时间后可能恢复正常。

2)响应头部

与请求头部类似,为响应报文添加了一些附加信息

常见响应头部如下:

响应头说明
Server服务器应用程序软件的名称和版本
Content-Type响应正文的类型(是图片还是二进制字符串)
Content-Length响应正文长度
Content-Charset响应正文使用的编码
Content-Encoding响应正文使用的数据压缩格式
Content-Language响应正文使用的语言

响应示例:

这里写图片描述


7、 一次完整的HTTP请求所经历的7个步骤

HTTP通信机制是在一次完整的HTTP通信过程中,Web浏览器与Web服务器之间将完成下列7个步骤:

1. 建立TCP连接
在HTTP工作开始之前,Web浏览器首先要通过网络与Web服务器建立连接,该连接是通过TCP来完成的,该协议与IP协议共同构建 Internet,即著名的TCP/IP协议族,因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议,根据规则, 只有低层协议建立之后才能,才能进行更层协议的连接,因此,首先要建立TCP连接,一般TCP连接的端口号是80。

2. Web浏览器向Web服务器发送请求命令
一旦建立了TCP连接,Web浏览器就会向Web服务器发送请求命令。例如:GET/sample/hello.jsp HTTP/1.1。

3. Web浏览器发送请求头信息
浏览器发送其请求命令之后,还要以头信息的形式向Web服务器发送一些别的信息,之后浏览器发送了一空白行来通知服务器,它已经结束了该头信息的发送。

4. Web服务器应答
客户机向服务器发出请求后,服务器会客户机回送应答, HTTP/1.1 200 OK ,应答的第一部分是协议的版本号和应答状态码。

5. Web服务器发送应答头信息
正如客户端会随同请求发送关于自身的信息一样,服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

6. Web服务器向浏览器发送数据
Web服务器向浏览器发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。

7. Web服务器关闭TCP连接
一般情况下,一旦Web服务器向浏览器发送了请求数据,它就要关闭TCP连接,然后如果浏览器或者服务器在其头信息加入了这行代码:
Connection:keep-alive
TCP连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。


8、常见的HTTP相应状态码

200 OK:请求已成功,请求所希望的响应头或数据体将随此响应返回。
201 Created :请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话,应当返回 ‘202 Accepted’。
202 Accepted :服务器已接受请求,但尚未处理。正如它可能被拒绝一样,最终该请求可能会也可能不会被执行。在异步操作的场合下,没有比发送这个状态码更方便的做法了。
204 No Content:请求被受理但没有资源可以返回
206 Partial Content:服务器已经成功处理了部分 GET 请求。

301 Moved Permanently:永久性重定向,请求的网页已永久移动到新位置。
302 Move temporarily:临时重定向,服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来响应以后的请求。
303 See Other:与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,能通过GET方法重定向到另一个URI上
304 Not Modified:如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变
307 Temporary Redirect:临时重定向,请求的资源临时从不同的URI 响应请求。

400 Bad Request:请求报文语法有误,服务器无法识别
401 Unauthorized:请求需要认证
403 Forbidden:请求的对应资源禁止被访问
404 Not Found:服务器无法找到对应资源

500 Internal Server Error:服务器内部错误(一般来说,这个问题都会在服务器端的源代码出现错误时出现。)
503 Service Unavailable:由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。
504 Gateway Timeout :服务器作为网关或代理,但是没有及时从上游服务器收到请求。


9、常见HTTP首部字段

a、通用首部字段(请求报文与响应报文都会使用的首部字段)
Date:创建报文时间
Connection:连接的管理
Cache-Control:缓存的控制
Transfer-Encoding:报文主体的传输编码方式

b、请求首部字段(请求报文会使用的首部字段)
Host:请求资源所在服务器
Accept:可处理的媒体类型
Accept-Charset:可接收的字符集
Accept-Encoding:可接受的内容编码
Accept-Language:可接受的自然语言

c、响应首部字段(响应报文会使用的首部字段)
Accept-Ranges:可接受的字节范围
Location:令客户端重新定向到的URI
Server:HTTP服务器的安装信息

d、实体首部字段(请求报文与响应报文的的实体部分使用的首部字段)
Allow:资源可支持的HTTP方法
Content-Type:实体主类的类型
Content-Encoding:实体主体适用的编码方式
Content-Language:实体主体的自然语言
Content-Length:实体主体的的字节数
Content-Range:实体主体的位置范围,一般用于发出部分请求时使用


10、cookie和session原理及区别

cookie采用的是客户端的会话状态的一种储存机制。它是服务器在本地机器上存储的小段文本或者是内存中的一段数据,并随每一个请求发送至同一个服务器。

session是一种服务器端的信息管理机制,它把这些文件信息以文件的形式存放在服务器的硬盘空间上(这是默认情况,可以用memcache把这种数据放到内存里面)当客户端向服务器发出请求时,要求服务器端产生一个session时,服务器端会先检查一下,客户端的cookie里面有没有session_id,是否过期。如果有这样的session_id的话,服务器端会根据cookie里的session_id把服务器的session检索出来。如果没有这样的session_id的话,服务器端会重新建立一个。PHPSESSID是一串加了密的字符串,它的生成按照一定的规则来执行。同一客户端启动二次session_start的话,session_id是不一样的。

1.区别:

Cookie保存在客户端浏览器中,而Session保存在服务器上。Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话,那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案,客户来访的时候只需要查询客户档案表就可以了。

1)cookie数据存放在客户的浏览器上,session数据放在服务器上
2)cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
3)session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能。考虑到减轻服务器性能方面,应当使用COOKIE。
4)单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
5)所以个人建议:
登陆信息等重要信息存放为SESSION
其他信息如果需要保留,可以放在COOKIE中


11.session产生的session_id放在cookie里面,如果用户把cookie禁止掉,是不是session也不能用了呢?

禁止掉cookie后,session当然可以用,不过通过其他的方式来获得这个sessionid,比如,可以跟在url的后面,或者以表单的形势提交到服务器端。从而使服务器端了解客户端的状态。

在默认的JSP、PHP配置中,SessionID是需要存储在Cookie中的,默认Cookie名为:

  • PHPSESSIONID
  • JSESSIONID

以下以PHP为例:

你第一次访问网站时,
服务端脚本中开启了Sessionsession_start();,
服务器会生成一个不重复的 SESSIONID 的文件session_id();,比如在/var/lib/php/session目录
并将返回(Response)如下的HTTP头 Set-Cookie:PHPSESSIONID=xxxxxxx
客户端接收到Set-Cookie的头,将PHPSESSIONID写入cookie
当你第二次访问页面时,所有Cookie会附带的请求头(Request)发送给服务器端
服务器识别PHPSESSIONID这个cookie,然后去session目录查找对应session文件,
找到这个session文件后,检查是否过期,如果没有过期,去读取Session文件中的配置;如果已经过期,清空其中的配置。

如果客户端禁用了Cookie,那PHPSESSIONID都无法写入客户端,Session还能用?

答案显而易见:不能。并且服务端因为没有得到PHPSESSIONID的cookie,会不停的生成session_id文件。

取巧传递session_id:

但是这难不倒服务端程序,聪明的程序员想到,如果一个Cookie都没接收到,基本上可以预判客户端禁用了Cookie,那将session_id附带在每个网址后面(包括POST),
比如:

GET http://www.xx.com/index.php?session_id=xxxxx 
POST http://www.xx.com/post.php?session_id=xxxxx

然后在每个页面的开头使用session_id($_GET['session_id']),来强制指定当前session_id

这样,答案就变成了:

聪明的你肯定想到,那将这个网站发送给别人,那么他将会以你的身份登录并做所有的事情。(目前很多订阅公众号就将openid附带在网址后面,这是同样的漏洞)。

其实不仅仅如此,cookie也可以被盗用,比如XSS注入,通过XSS漏洞获取大量的Cookie,也就是控制了大量的用户,腾讯有专门的XSS漏洞扫描机制,因为大量的QQ盗用,发广告就是因为XSS漏洞

所以Laravel等框架中,内部实现了Session的所有逻辑,并将PHPSESSIONID设置为httponly并加密,这样,前端JS就无法读取和修改这些敏感信息,降低了被盗用的风险。


12.为什么说session 比cookie更安全?

真正的cookie存在于客户端硬盘上的一个文本文件,如果两者一样的话,只要cookie就好了,让客户端来分提服务器的负担,并且对于用户来说又是透明的。但实际上不是。

session的sessionID是放在cookie里,要想功破session的话,得分两步:

第一要得到sessionID。攻破cookie后,你要得到sessionID,sessionID是要有人登录,或者启动session_start才会有,你不知道什么时候会有人登录。

第二取有效sessionID。sessionID是加密的,第二次session_start的时候,前一次的sessionID就没有用了,session过期时sessionid也会失效,想在短时间内功破加了密的 sessionID很难
session是针对某一次通信而言,会话结束session也就随着消失了。


13.Cookie与Session问答

  1. Cookie运行在客户端,Session运行在服务端,对吗?

    A:不完全正确。Cookie是运行在客户端,有客户端进行管理;Session虽然是运行在服务器端,但是sessionID作为一个Cookie是存储在客户端的

  2. 浏览器禁止Cookie,Cookie就不能用了,但Session不会受浏览器影响,对吗?

    A:错。浏览器禁止Cookie,Cookie确实不能用了,Session会受浏览器端的影响。很简单的实验,在登录一个网站后,清空浏览器的Cookie和隐私数据,单机后台的连接,就会因为丢失Cookie而退出。当然,有办法通过URL传递Session。

  3. 浏览器关闭后,Cookie和Session都消失了,对吗?

    A:错。存储在内存中额Cookie确实会随着浏览器的关闭而消失,但存储在硬盘上的不会。更顽固的是Flash Cookie,不过现在很多系统优化软件和新版浏览器都已经支持删除FlashCookie。百度采用了这样的技术记忆用户:Session在浏览器关闭后也不会消失,除非正常退出,代码中使用了显示的unset删除Session。否则Session可能被回收,也有可能永远残留在系统中。

  4. Session 比 Cookie 更安全吗? 不应该大量使用Cookie吗?

    A:错误。Cookie确实可能存在一些不安全因素,但和JavaScript一样,即使突破前端验证,还有后端保障安全。一切都还要看设计,尤其是涉及提权的时候,特别需要注意。通常情况下,Cookie和Session是绑定的,获得Cookie就相当于获得了Session,客户端把劫持的Cookie原封不动地传给服务器,服务器收到后,原封不动地验证Session,若Session存在,就实现了Cookie和Session的绑定过程。因此,不存在Session比Cookie更安全这种说法。如果说不安全,也是由于代码不安全,错误地把用作身份验证的Cookie作为权限验证来使用。

  5. Session是创建在服务器上的,应该少用Session而多用Cookie,对吗?

    A:错。Cookie可以提高用户体验,但会加大网络之间的数据传输量,应尽量在Cookie中仅保存必要的数据。

  6. 如果把别人机器上的Cookie文件复制到我的电脑上(假设使用相同的浏览器),是不是能够登录别人的帐号呢?如何防范?

    A:是的。这属于Cookie劫持的一种做法。要避免这种情况,需要在Cookie中针对IP、UA等加上特殊的校验信息,然后和服务器端进行比对。

  7. 在IE浏览器下登录某网站,换成Firefox浏览器是否仍然是未登录状态?使用IE登录了腾讯网站后,为什么使用Firefox能保持登录状态?

    A:不同浏览器使用不同的Cookie管理机制,无法实现公用Cookie。如果使用IE登录腾讯网站,使用Firefox也能登录,这是由于在安装腾讯QQ软件时,你的电脑上同时安装了针对这两个浏览器的插件,可以识别本地已登录QQ号码进而自动登录。本质上,不属于共用Cookie的范畴。
    


14.怎么理解http的无状态无连接?

无连接:服务器处理完客户的请求,并收到客户的应答后,即断开连接。

早期这么做的原因是:

HTTP协议产生于互联网,因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问,但每个客户端(即浏览器)与服务器之间交换数据的间歇性较大(即传输具有突发性、瞬时性),并且网页浏览的联想性、发散性导致两次传送的数据关联性很低,如果按照上面的方式则需要在服务器端开的进程和句柄数目都是不可接受的,象paranoid945所说的,大部分通道实际上会很空闲、无端占用资源。因此HTTP的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接,以尽快将资源释放出来服务其他客户端。

随着时间的推移,html页面变得复杂了,里面可能嵌入了很多图片,这时候每次访问图片都需要建立一次tcp连接就显得低效了。因此Keep-Alive被提出用来解决效率低的问题。

这样一来,客户端和服务器之间的HTTP连接就会被保持,不会断开(超过Keep-Alive规定的时间,意外断电等情况除外),当客户端发送另外一个请求时,就使用这条已经建立的连接。

无状态是指服务器不知道客户端是什么状态。

HTTP协议是无状态的,指的是协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。也就是说,打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议,无状态不代表HTTP不能保持TCP连接,更不能代表HTTP使用的是UDP协议(无连接)。

HTTP是一个无状态协议,这意味着每个请求都是独立的,Keep-Alive没能改变这个结果。

然而,随着时间的推移,人们发现静态的HTML着实无聊而乏味,增加动态生成的内容才会令Web应用程序变得更加有用。于是乎,HTML的语法在不断膨胀,其中最重要的是增加了表单(Form);客户端也增加了诸如脚本处理、DOM处理等功能;对于服务器,则相应的出现了CGI(Common Gateway Interface)以处理包含表单提交在内的动态请求。

在这种客户端与服务器进行动态交互的Web应用程序出现之后,HTTP无状态的特性严重阻碍了这些交互式应用程序的实现,毕竟交互是需要承前启后的,简单的购物车程序也要知道用户到底在之前选择了什么商品。于是,两种用于保持HTTP状态的技术就应运而生了,一个是Cookie,而另一个则是Session。

下面是关于cookie和session的一篇文章,少年已经总结的相当好了,直接拿来~
http://www.blogjava.net/cheneyfree/archive/2007/05/26/120168.html

Cookie是客户端的存储空间,由浏览器来维持。具体来说cookie机制采用的是在客户端保持状态的方案,而session机制采用的是在服务器端保持状态的方案。同时我们也看到,由于在服务器端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助于cookie机制来达到保存标识的目的,但实际上还有其他选择,比如说重写URL和隐藏表单域


15.理解HTTP长连接和短连接?

1. HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议,在传输层使用TCP协议,在网络层使用IP协议。IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠的传递数据包,使在网络上的另一端收到发端发出的所有包,并且顺序与发出顺序一致。TCP有可靠,面向连接的特点。

2.什么是长连接、短连接?

  在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话。

从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头有加入这行代码:Connection:keep-alive

在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。

3.TCP短连接

我们模拟一下TCP短连接的情况,client向server发起连接请求,server接到请求,然后双方建立连接。client向server 发送消息,server回应client,然后一次读写就完成了,这时候双方任何一个都可以发起close操作,不过一般都是client先发起 close操作。为什么呢,一般的server不会回复完client后立即关闭连接的,当然不排除有特殊的情况。从上面的描述看,短连接一般只会在 client/server间传递一次读写操作

短连接的优点是:管理起来比较简单,存在的连接都是有用的连接,不需要额外的控制手段

4. TCP长连接

接下来我们再模拟一下长连接的情况,client向server发起连接,server接受client连接,双方建立连接。Client与server完成一次读写之后,它们之间的连接并不会主动关闭,后续的读写操作会继续使用这个连接。

首先说一下TCP/IP详解上讲到的TCP保活功能,保活功能主要为服务器应用提供,服务器应用希望知道客户主机是否崩溃,从而可以代表客户使用资源。如果客户已经消失,使得服务器上保留一个半开放的连接,而服务器又在等待来自客户端的数据,则服务器将应远等待客户端的数据,保活功能就是试图在服务 器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何的动作,则服务器就向客户发一个探测报文段,客户主机必须处于以下4个状态之一:

1)客户主机依然正常运行,并从服务器可达。客户的TCP响应正常,而服务器也知道对方是正常的,服务器在两小时后将保活定时器复位。

2)客户主机已经崩溃,并且关闭或者正在重新启动。在任何一种情况下,客户的TCP都没有响应。服务端将不能收到对探测的响应,并在75秒后超时。服务器总共发送10个这样的探测 ,每个间隔75秒。如果服务器没有收到一个响应,它就认为客户主机已经关闭并终止连接。

3)客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应,这个响应是一个复位,使得服务器终止这个连接。

4)客户机正常运行,但是服务器不可达,这种情况与2类似,TCP能发现的就是没有收到探查的响应。

5.长连接短连接操作过程

短连接的操作步骤是:

建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接

长连接的操作步骤是:

建立连接——数据传输…(保持连接)…数据传输——关闭连接

6. 长连接和短连接的优点和缺点

由上可以看出,长连接可以省去较多的TCP建立和关闭的操作,减少浪费,节约时间。对于频繁请求资源的客户来说,较适用长连接。不过这里存在一个问题,存活功能的探测周期太长,还有就是它只是探测TCP连接的存活,属于比较斯文的做法,遇到恶意的连接时,保活功能就不够使了。在长连接的应用场景下,client端一般不会主动关闭它们之间的连接,Client与server之间的连接如果一直不关闭的话,会存在一个问题,随着客户端连接越来越多,server早晚有扛不住的时候,这时候server端需要采取一些策略,如关闭一些长时间没有读写事件发生的连接,这样可 以避免一些恶意连接导致server端服务受损;如果条件再允许就可以以客户端机器为颗粒度,限制每个客户端的最大长连接数,这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单,存在的连接都是有用的连接,不需要额外的控制手段。但如果客户请求频繁,将在TCP的建立和关闭操作上浪费时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略,具体的应用场景采用具体的策略,没有十全十美的选择,只有合适的选择。

7. 什么时候用长连接,短连接?

长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费

而像WEB网站的http服务一般都用短连接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频繁操作情况下需用短连好。


16.PC网络故障,如何排除障碍

https://wenku.baidu.com/view/7960c408b14e852459fb578a.html

这里写图片描述
这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述


17.哪些应用用到TCP,哪些是UDP

21/tcp FTP 文件传输协议
22/tcp SSH 安全登录、文件传送(SCP)和端口重定向
23/tcp Telnet 不安全的文本传送
25/tcp SMTP Simple Mail Transfer Protocol (E-mail)
69/udp TFTP Trivial File Transfer Protocol
79/tcp finger Finger
80/tcp HTTP 超文本传送协议 (WWW)
88/tcp Kerberos Authenticating agent
110/tcp POP3 Post Office Protocol (E-mail)
113/tcp ident old identification server system
119/tcp NNTP used for usenet newsgroups
220/tcp IMAP3
443/tcp HTTPS used for securely transferring web pages

首先还是把协议特性说一下,明白了特性自然知道应用场合了,嘿嘿!两种协议都是传输层协议,为应用层提供信息载体。TCP协议是基于连接的可靠协议,有流量控制和差错控制,也正因为有可靠性的保证和控制手段,所以传输效率比UDP低;UDP协议是基于无连接的不可靠协议,没有控制手段,仅仅是将数据发送给对方,因此效率比TCP要高。

基于上述特性,不难得到结论,TCP协议适用于对效率要求相对低,但对准确性要求相对高的场景下,或者是有一种连接概念的场景下;而UDP协议适用于对效率要求相对高,对准确性要求相对低的场景。

好了,现在回到你的问题,举几个应用的例子。
TCP一般用于文件传输(FTP HTTP 对数据准确性要求高,速度可以相对慢),
发送或接收邮件(POP IMAP SMTP 对数据准确性要求高,非紧急应用),
远程登录(TELNET SSH 对数据准确性有一定要求,有连接的概念)等等;

UDP一般用于即时通信(QQ聊天 对数据准确性和丢包要求比较低,但速度必须快),
在线视频(RTSP 速度一定要快,保证视频连续,但是偶尔花了一个图像帧,人们还是能接受的),
网络语音电话(VoIP 语音数据包一般比较小,需要高速发送,偶尔断音或串音也没有问题)等等。

作为知识的扩展,可以再说一些其他应用。比如,TCP可以用于网络数据库分布式高精度计算系统的数据传输;UDP可以用于服务系统内部之间的数据传输,因为数据可能比较多,内部系统局域网内的丢包错包率又很低,即便丢包,顶多是操作无效,这种情况下,UDP经常被使用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值