day2 网络基础

参考

基础知识

OSI七层模型及其功能

OSI模型
  • 物理层:负责最后将信息编码成电流脉冲或其他信号用于网上传输
  • 数据链路层:通过物理网络链路层提供数据传输,不同的数据链路层定义了不同的网络和协议特征,其中包括物理编址,网络拓扑结构,错误验证,数据帧序列等
  • 网络层:负责在源和终点之间建立连接
  • 传输层:向高层提供可靠的端到端的网络数据流服务
  • 会话层:会话层建立,管理,和终止表示层与实体之间的通信会话
  • 表示层:提供多种功能用于应用层数据编码和转化,以确保以一个系统应用层发送的信息可以被另一个系统应用层识别
  • 应用层:包括文件的传输、访问及管理协议(FTAM) ,以及文件虚拟终端协议(VIP)和公用管理系统信息(CMIP)等;
    常见的应用层协议:


    常见的应用层协议

5层协议

  • 物理层
  • 链接层:在物理层上
    • 协议:以太网协议规定了电信号的分组方式
    • mac地址
    • 广播(局限于子网)
  • 网络层:建立一个主机到主机的链接,能够区分哪些MAC地址属于同一个子网络,使得我们能够区分不同的计算机是否属于同一个子网络
    • ip协议
    • ip数据包
    • arp协议,能够从IP地址得到MAC地址
  • 传输层:建立一个端口到端口的链接
  • 应用层:规定应用程序的数据格式

TCP/UDP协议

UDP数据包

四层协议

  • 网络接口层:用于协作IP数据在已有网络介质上传输的协议
  • 网间层:网间层对应于 OSI 七层参考模型的网络层,本层包含 IP 协议、RIP 协议(Routing Information Protocol,路由信息协议),负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来􏰁供网络诊断信息;
  • 传输层:传输层对应于 OSI 七层参考模型的传输层,它􏰁供两种端到端的通信服务。其中 TCP 协议(Transmission Control Protocol)提供可靠的数据流运输服务,UDP 协议(Use Datagram Protocol)提供不可靠的用户数据报服务。
  • 应用层:应用层对应于 OSI 七层参考模型的应用层和表达层;

TCP/IP 协议族常用协议

  • 应用层:TFTP,HTTP,SNMP,FTP,SMTP,DNS,Telnet 等等
  • 传输层:TCP,UDP
  • 网络层:IP,ICMP,OSPF,EIGRP,IGMP
  • 数据链路层:SLIP,CSLIP,PPP,MTU

各种协议简单介绍

  • IP(Internet Protocol,网际协议):IP 定义了 TCP/IP 的地址,寻址方法,以及路由规则;IP 地址由两部分组成,即网络号和主机号;IPv6 是为了解决 IPv4 地址耗尽和其它一些问题而研发的最新版本的 IP。使用 128 位 整数表示地址
  • ICMP(Internet Control Message Protocol,网络控制消息协议):是 TCP/IP 的 核心协议之一,用于在 IP 网络中发送控制消息,提供通信过程中的各种问题反馈
  • TCP(TransmissionControlProtocol,传输控制协议):是一种面向连接的,可靠的, 基于字节流传输的通信协议。
  • UDP(UserDatagramProtocol,用户数据报协议):是一个面向数据报的传输层协 议
  • ECHO(EchoProtocol,回声协议):是一个简单的调试和检测工具。服务器器会 原样回发它收到的任何数据,既可以使用 TCP 传输,也可以使用 UDP 传输。使用 端口号 7 。
  • DHCP(DynamicHostConfigrationProtocol,动态主机配置协议):是用于局域 网自动分配 IP 地址和主机配置的协议。可以使局域网的部署更加简单。
  • DNS(DomainNameSystem,域名系统)是互联网的一项服务,可以简单的将用“.” 分隔的一般会有意义的域名转换成不易记忆的 IP 地址。
  • FTP(FileTransferProtocol,文件传输协议)是用来进行文件传输的标准协议。
  • TFTP(Trivial File Transfer Protocol,简单文件传输协议)是一个简化的文 件传输协议,其设计非常简单,通过少量存储器就能轻松实现,所以一般被用来通 过网络引导计算机过程中传输引导文件等小文件;
  • SSH(SecureShell,安全Shell),因为传统的网络服务程序比如TELNET本质上都极不安全,明文传说数据和用户信息包括密码,SSH 被开发出来避免这些问题, 它其实是一个协议框架,有大量的扩展冗余能力,并且提供了加密压缩的通道可以 为其他协议使用。
  • POP(PostOfficeProtocol,邮局协议)是支持通过客户端访问电子邮件的服务, 现在版本是 POP3,也有加密的版本 POP3S。协议使用 TCP,端口 110。
  • SMTP(Simple Mail Transfer Protocol,简单邮件传输协议)是现在在互联网 上发送电子邮件的事实标准。使用 TCP 协议传输,端口号 25。
  • HTTP(HyperTextTransferProtocol,超文本传输协议)是现在广为流行的WEB 网络的基础,HTTPS 是 HTTP 的加密安全版本。协议通过 TCP 传输,HTTP 默认 使用端口 80,HTTPS 使用 443。

TCP协议建立连接和终止连接的过程?

建立连接:

1、服务器端必须做好准备接受外来的连接。这通常通过 socket(), bind(), listen() 三个函数来完成的。我们称之为 被动打开(passive open).
2、客户端通过调用connect发起主动打开(active open)。这导致客户端TCP发送SYN同步分节。它告诉服务器客户端在(待建立的)连接中发送的数据的初始化序列号。通用SYN分节不携带数据,
3、服务器必须确认(ACK) 客户端的SYN,同时自己也得发送一个SYN分节,它含有服务器将在统一连接中发送的数据的初始化序号。服务器在单个分节中发送SYN和对客户端SYN的ACK确认。
4、客户端必须确认服务器的SYN。

三次握手

连接终止:

1、某个应用程序首先调用close,主动关闭(active close) 该端的TCP于是发送一个FIN分节,表示数据发送完毕。
2、接收到这个FIN的对端执行被动关闭(passive close)。这个FIN是TCP确认。它的接收也作为一个文件结束符(end of file) 传递给接收端的应用程序(放在排队等候应用进程接收的任何其他数据之后),因为FIN的接收意味着接收端应用程序在相应连接上再无额外数据可以接收。
3、一段时间以后,接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。
4、接收这个最终FINd额原发送端TCP(即执行主动关闭的一端)确认这个FIN

四次挥手

区别:

TCP :传输控制协议。
a、面向连接,靠三次握手来完成
b、速度相对较慢,因为连接的过程会耗时间和资源
c、可靠的协议,数据不会丢失
d、数据大小没有限制
e、耗用系统资源相对较多
UDP:用户数据报文协议
a、面向无连接的
b、高效的、速度快
c、不可靠的协议,容易丢失数据
d、数据包大小有限制,小于64K
e、耗用系统资源相对较少

HTTP

  • HTTP:HyperText Transfer Protocol 超文本传输协议,处于应用层,基于请求响应模式,无状态(对以前的连接无记忆)协议。

URL与URI的区别

  • URL:Uniform Resource Location 统一资源定位器,就是常说的网页地址。组成部分:协议;存有该资源的主机IP地址;主机资源的具体地址,强调的是路径
  • URI:uniform resource identifier 统一资源表示符,用来唯一的表示一个资源,包括三个组成部分:访问资源的命名机制;存放资源的主机名;资源本身的名称,有路径表示,着重强调与资源。例:file://a:1234/b/c/d.txt

http1.0月http1.1的区别

  • http1.0所做的优化:
    • 带宽问题
    • 延迟问题:1,浏览器阻塞:浏览器对于同一个域名,同时只能有4个连接;2.DNS查询:浏览器需要知道目标服务器的IP才能建立连接;3.建立连接:三次握手
  • 具体区别:1.缓存处理;2.带宽处理及网络连接的使用;3.host头处理;4.长连接

http1.1和http1.0存在的问题

  • http1.0在传输数据时,每次都需要重新建立连接,无疑增加了大量的延迟时间
  • http1.x在传输数据时,所有传输的内容都是明文,客户端和服务端都无法验证对方的身份
  • http1.1在使用时,header里携带的内容过大,在一定程度行增加了传输的成本
  • 虽然http1.1支持了keep-alive,来弥补多次创建连接产生的延迟,但是keep-alive使用多了同样会给服务端带来大量的性能压力

cookie和session

Cookie:Cookie技术是客户端的解决方案,Cookie就是由服务器发给客户端的特殊信息,而这些信息已文本文件的方式存放在客户端,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息

Cookie,弥补http的无状态

Session:是另一种记录客户端状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器吧客户端信息已某种形式记录在服务器上。

session的工作原理
1.创建session
2.创建Session的同时,服务器会为该Session生成唯一的Session id
3.在Session被创建之后,就可以调用Session相关的方法往Session中增加内容
4.当客户端再次发送请求的时候,会将这个Session id带上,服务器接收到请求之后就会依据Session id找到相应的Session

区别

  • 存放位置不同
  • 存取方式的不同
  • 安全性的不同
  • 有效期上的不同
  • 对服务器造成的压力不同

HTTP与HTTPS的区别

https架构图
https协议包

HTTPS = HTTP + SSL/TLS,HTTPS使用SSL/TLS进行加密,这既是它的优点也是它的缺点,加密使HTTPS的安全性大大提高,但是加密的过程也导致通信过程中性能的下降。

HTTPS中SSL/TLS加密的握手过程

握手过程

以下的C代表Client客户端,S代表Server服务端。
1.C告诉S:协议版本号,支持的加密方法,以及自己生成的随机数
2.S确认加密方法,给C方松证书和自己产生的随机数
3.C确认证书有效性,产生新的随机数,并使用数字证书中的公钥加密随机数,发送给S
4.S使用对应的私钥解密得到C发过来的随机数
5.C和S使用约定的加密方法,使用前面的三个随机数,生成对话密钥,然后用此密钥加密接下来的整个对话过程
总的来说,整个过程就是使用非对称加密算法交换“对话中要使用的对称加密算法的密钥”,然后使用对称加密算法进行对话。

相关加密算法

  • 对称加密:共享密钥加密,对称密钥在加密和解密的过程中使用的密钥是相同的,常见的对称加密算法有DES,3DES,AES,RC5,RC6。优点是计算速度快,缺点是密钥需要 字啊通讯的两端共享
  • 非对称加密:公开密钥加密,服务端会生成一对密钥,一个私钥保存在服务端,仅自己知道,另一个是公钥,公钥可以自由发布供任何人使用
  • 数字签名
  • 数字证书

HTTP 报文

  • 请求报文

一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成


http请求报文一般格式
  • 响应报文

HTTP响应也由三个部分组成,分别是:状态行、消息报头、响应正文。
<status-line>
<headers>
<blank line>
[<response-body>]

常见响应类别

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:服务器当前不能处理客户端的请求,一段时间后可能恢复正常,举个例子:HTTP/1.1 200 OK(CRLF)。

Http的get和post方法的区别什么?

get方法:

原理上:主要用来获取或者查询资源信息。就是说不修改信息
表面上:
a、GET请求的数据会附在URL之后(就是把数据放在HTTP协议头中),以?分割URL和传输数据,参数之间以&相 连
b、GET方式提交的数据较小(浏览器和操作系统对URL长度的限定),一般1024字节
c、GET的安全性相对较弱,可能会造成信息泄露(信息会明文出现在URL上,其他人可能会通过浏览器的缓存查 看到历史记录,从而得到信息)
d、服务器端用Request.QueryString获取变量的值
e、GET请求用起来比比较方便

post方法:

原理上:根据Http规范,POST表示可能修改服务器上资源的请求
表面上:a、POST请求把要提交的数据放在HTTP包的包体中。
b、POST可以提交较大量的数据(受到服务器的处理程序的处理能力限制)
c、POST安全性较高(数据不会明文出现在URL上)。
d、服务器端用Request.Form获取提交的数据。
e、用起来相对麻烦一点

DNS解析过程

DNS的解析过程

DNS功能是将域名解析为IP地址。
1.查找浏览器缓存,是否有解析记录,没有则进入第二步
2.查找系统缓存,是否有解析记录,没有则进入第二步
3.给配置的DNS服务器(LDNS)发送请求,LDNS查找到则返回
4.LDNS没有找到时会请求RootServer,返回一个顶级域名服务器
5.LDNS请求顶级域名服务器,返回NameServer地址
6.NameServer返回IP给LDNS,LDNS会进行缓存
7.LDNS返回给用户

socket

创建socket实例
客户端链接
创建Socket对象
连接建立后,通过输出流向服务器发送请求消息
通过输入流获取服务器响应的信息
关闭响应资源

服务端连接

创建ServerSocket对象,绑定监听对象
通过accept()方法监听客户端请求
连接建立后,通过输入流读取客户端发送的请求信息
通过输出流向客户端发送信息
关闭相关资源

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,835评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,598评论 1 295
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,569评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,159评论 0 213
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,533评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,710评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,923评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,674评论 0 203
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,421评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,622评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,115评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,428评论 2 254
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,114评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,097评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,875评论 0 197
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,753评论 2 276
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,649评论 2 271

推荐阅读更多精彩内容