OSI模型，即開放式通信系統互聯參考模型(Open System Interconnection,OSI/RM,Open Systems InterconnectionReference Model)，是國際標準化組織(ISO)提出的一個試圖使各種計算機在世界范圍內互連為網絡的標準框架，簡稱OSI。
0SI／RM協議是由IS0(國際標準化組織)制定的，它有三個基本的功能：提供給開發者一個必須的、通用的概念以便開發完善、可以用來解釋連接不同系統的框架。
95【中國自動化網社區】c2bd23【http://sns.ca800.com】9d2
8825668【中國自動化網社區】6c850d【http://sns.ca800.com】a2eb3
OSI的層次劃分：OSI將計算機網絡體系結構(architecture)劃分為以下七層：
1、物理層 ?Physical Layer
物理接口規范，傳輸比特流,網卡是工作在物理層的。
2、數據鏈路層 ?Data Link Layer
成幀，保證幀的無誤傳輸，MAC地址，形成EHTHERNET幀
3、網絡層 ?Network Layer
路由選擇，流量控制，IP地址，形成IP包
4、傳輸層 ?Transport Layer
端口地址，如HTTP對應80端口。TCP和UDP工作于該層,還有就是差錯校驗和流量控制。
5、會話層 ?Session Layer
組織兩個會話進程之間的通信,并管理數據的交換使用NETBIOS和WINSOCK協議。QQ等軟件進行 ? ? ? ?通訊因該是工作在會話層的。
6、表示層 ?Presentation Layer
使得不同操作系統之間通信成為可能。
7、應用層 Application Layer
對應于各個應用軟件
它和我們常用的TCP/IP的協議層有些相似，TCP/IP把1和2封裝為一層，3和4還是獨立的層，5和6和7封裝成為一層，也就是說TCP/IP只有四層，但是在此我講述的7層的具體意義。
在這里我將假設一個場景，那就是把要傳輸數據的一方視為某個公司的經理，網絡傳輸被視為這個經理要把一件事情告訴另一個公司的經理。
網絡的A端：
1、應用層：A公司經理把他想要告訴B公司經理的事情用嘴講了出來。
用戶的應用程序懷網絡之間的接口 老板
2、表示層：秘書就把A公司經理說的事情翻譯成為英文然后寫在了紙上。
協商數據交換格式 相當公司中簡報老板、替老板寫信的助理
3、會話層：行政的職員把秘書寫的這封信，裝到了信封封裝好了，寫上了信封的信息。
允許用戶使用簡單易記的名稱建立連接 相當于公司中收寄信、寫信封與拆信封的秘書
4、傳輸層：A郵局的職工把這封信取走。
提供終端到終端的可靠連接 相當于公司中跑郵局的送信職員
5、網絡層：A郵局的分派的職工，把這封信分派到指定送信區域。
使用權數據路由經過大型網絡 相當于郵局中的排序工人
6、數據鏈路層：A郵局的裝箱的職工，就把一同送往這個區域的信封裝到一個木箱子里，然后送到A郵局物流站。
決定訪問網絡介質的方式 相當于郵局中的裝拆箱工人
7、物理層：A郵局的物流職工把木箱運到鐵路
將數據轉換為可通過物理介質傳送的電子信號 相當于郵局中的搬運工人
這里的鐵路就是網絡連接物理介質
網絡的B端：
7、物理層：B郵局的物流職工把木箱從鐵路運到郵局的物流站。
6、數據鏈路層：B郵局的拆箱的職工把物流站的木箱拆箱然后把所有的信件取出來。
5、網絡層：B郵局的分派的職工，把這封信分派到指定送信區域。
4、傳輸層：B郵局的職工把這封信送到B公司。
3、會話層：B公司行政的職員把公司的信件整理并且拆封信件（假設這是公司允許的情況下）并送到各自部門的秘書手里。
2、表示層：B公司秘書把信上的英文翻譯成為中文。
1、應用層：B公司經理聽秘書轉述給他這封信的內容。
到此為止一個完整的通過這7層的網絡通訊順利完成。接下來我將用技術術語并結合TCP/IP中的應用再描述一遍這7層協議。
（1）應用層：與其他計算機進行通訊的一個應用，它是對應應用程序的通信服務的。例如，一個沒有通信功能的字處理程序就不能執行通信的代碼，從事字處理工作的程序員也不關心OSI的第7層。但是，如果添加了一個傳輸文件的選項，那么字處理器的程序員就需要實現OSI的第7層。
應用層為操作系統或網絡應用程序提供訪問網絡服務的接口。
應用層是模型中的最頂層，是用戶與網絡的接口，該層通過應用程序來完成網絡用戶的應用需求。該層的數據放在TCP數據包的數據部分，該層定義了一個很重要的協議——Http協議，我們一般的Web開發都是基于應用層的開發， 所以后面專題將會和大家介紹下Http協議。
既然知道http是大家在應用層的一個協議比如我們瀏覽網頁什么的就是http應用IOS上層也是基于http的協議比較簡單些，效率高靈活的比較難。
示例：Telnet(遠程登錄協議)、FTP(File Transfer Protocol)、HTTP(Hyperrext Transfer Protocol)、SNMP(simple Mail Transfer Protocol)BOOTP(Boot trap．Protocol)AFP（Apple Talk文件協議--Apple公司的網絡協議族，用于交換文件）SNMP(Simple Network Management Protoco1)
NCP(NetWare Core Protoco1)NFS(Network File System)
8825668【中國自動化網社區】6c850d【http://sns.ca800.com】a2eb3
（2）表示層：這一層的主要功能是定義數據格式及加密。例如，FTP允許你選擇以二進制或ASII格式傳輸。如果選擇二進制，那么發送方和接收方不改變文件的內容。如果選擇ASII格式，發送方將把文本從發送方的字符集轉換成標準的ASII后發送數據。在接收方將標準的ASII轉換成接收方計算機的字符集。示例：加密，ASII等。
表示層對上層數據或信息進行變換以保證一個主機應用層信息可以被另一個主機的應用程序理解。表示層的數據轉換包括數據的加密、壓縮、格式轉換等。
示例：
EBCDIC（extended binary coded decimal interchange code）、ASCII（Amercia Standard Code for Information Interchange）；
圖像標準：JPEG（Joint Photographic Experts Group）、TIFF（Tagged Image File Format）、GIF；
視頻標準：MIDI（Musical Instrument Digital Interface）、MPEG（Motion Picture Experts Group）、QuickTime等。
ad【中國自動化網社區】2c4082【http://sns.ca800.com】48
（3）會話層：他定義了如何開始、控制和結束一個會話，包括對多個雙向小時的控制和管理，以便在只完成連續消息的一部分時可以通知應用，從而使表示層看到的數據是連續的，在某些情況下，如果表示層收到了所有的數據，則用數據代表表示層。示例：RPC，SQL等。
會話層管理主機之間的會話進程，即負責建立、管理、終止進程之間的會話。會話層還利用在數據中插入校驗點來實現數據的同步。
示例：
SSH,Secure Shell
ZIP,Zone Information Protocol
SDP,Sockets Direct Protocol
ADSP：AppleTalk的數據流協議
ASP：AppleTalk的動態會話協議
H.245,Call Control Protocol for Multimedia Communication
ISO-SP,OSI Session Layer Protocol（X.225, ISO 8327）
iSNS,Internet Storage Name Service
NetBIOS,Network Basic Input Output System
PAP,Password Authentication Protocol
PPTP,Point-to-Point Tunneling Protocol
RPC,遠程過程調用
RTCP,實時傳輸控制協議
SMPP,Short Message Peer-to-Peer
SCP,Secure Copy Protocol
ad【中國自動化網社區】2c4082【http://sns.ca800.com】48
（4）傳輸層：這層的功能包括是否選擇差錯恢復協議還是無差錯恢復協議，及在同一主機上對不同應用的數據流的輸入進行復用，還包括對收到的順序不對的數據包的重新排序功能。
通過MAC和IP地址，我們可以找到互聯網上任意兩臺主機來建立通信。然而這里有一個問題，找到主機后，主機上有很多程序都需要用到網絡，比如說你在一邊聽歌和好用QQ聊天， 當網絡上發送來一個數據包時， 是怎么知道它是表示聊天的內容還是歌曲的內容的， 這時候就需要一個參數來表示這個數據包是發送給那個程序（進程）來使用的，這個參數我們就叫做端口號，主機上用端口號來標識不同的程序（進程），端口是0到65535之間的一個整數，0到1023的端口被系統占用，用戶只能選擇大于1023的端口。
傳輸層的功能就是建立端口到端口的通信，網絡層就是建立主機與主機的通信，這樣如果我們確定了主機和端口，這樣就可以實現程序之間的通信了。我們所說的Socket編程就是通過代碼來實現傳輸層之間的通信。因為初始化Socket類對象要指定IP地址和端口號。
在傳輸層有兩個非常重要的協議：UDP 協議和TCP協議
采用UDP協議話傳輸的就是UDP數據包，同樣UDP數據包也由頭和數據兩部分組成，頭部分主要標識了發送端口和接受端口，數據部分就是具體的內容信息。同樣UDP數據包是放入IP數據包中的"數據"部分，IP數據包再放入數據幀中在網絡上傳輸。
由于UDP協議的可靠性差（數據發送后無法確定對方是否收到），所以又定義了一個可靠性高的協議——TCP協議，TCP協議采取了握手的方式要確保對方收到了數據。
示例：TCP(Transmission Control Protocol)、UDP(User Datagram Protocol）、SPX(SequenCed Packet ExChange Protocol)等。ATP(AppleTalk Transaction Protocol)，NBP(名字綁定協議)NetBEUI(NetBIOS Extended User Internet)
ad【中國自動化網社區】2c4082【http://sns.ca800.com】48
（5）網絡層：這層對端到端的包傳輸進行定義，他定義了能夠標識所有結點的邏輯地址，還定義了路由實現的方式和學習的方式。為了適應最大傳輸單元長度小于包長度的傳輸介質，網絡層還定義了如何將一個包分解成更小的包的分段方法。
網絡層負責對子網間的數據包進行路由選擇。網絡層還可以實現擁塞控制、網際互連等功能。
在這一層，數據的單位稱為數據包（packet）。
該層通過尋址（尋址地址）來建立兩個節點之間的連接，大家都知道我們的電腦連接上網絡后都一個IP地址，我們可以通過IP地址來確定不同的計算機是否在同一個子網路。如果我們的電腦連接上網絡后就有兩種地址：物理地址和網絡地址（IP地址），網絡上的計算機要通信，必須要知道通信的計算機“在哪里”， 首先通過網絡地址來判斷是否處于同一個子網絡，然后再對物理地址（MAC）地址進行處理，從而準確確定要通信計算機的位置。
在網絡層中有我們熟悉的IP協議（即規定網絡地址的協議），目前廣泛采用的是IP協議第四版（IPv4）,這個版本規定，網絡地址由32位二進制位組成。我們可以自己配置IP地址也可以自動獲得的方式得到IP地址，Ip地址分成兩部分，前24位代表網絡，后8位代表主機號， 如192.168.254.1和192.168.254.2就處于同一個子網絡里，因為這兩個IP地址的前24位相同。
網絡層中以IP數據包的形式來傳遞數據，IP數據包也包括兩部分：頭（Head）和數據(Data)，IP數據包放進數據幀中的數據部分進行傳輸。
示例：IP(Internet Protocol)、IPX(Internet work Packet Exchange)、DDP(Datagram Delivery Protoco1)ICMP（Internet Control Message Protocol）APPLETALK、
6b3365【中國自動化網社區】652ace【http://sns.ca800.com】ba9338
（6）數據鏈路層：他定義了在單個鏈路上如何傳輸數據。這些協議與被討論的各種介質有關。
數據鏈路層在不可靠的物理介質上提供可靠的傳輸。該層的作用包括：物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。
在這一層，數據的單位稱為幀（frame）。
該層對接受到物理層傳輸過來的比特流進行分組，一組電信號構成的數據包，就叫做"幀"，數據鏈鏈路層就是來傳輸以"幀"為單位的數據包，把數據傳遞給上一層（網絡層），幀數據由兩部分組成：幀頭和幀數據，幀頭包括接受方物理地址（就是網卡的地址）和其他的網絡信息，幀數據就是要傳輸的數據體。數據幀的最長為1500字節，如果數據很長，就必須分割成多個幀進行發送。
示例：?ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼等。
（7）物理層：OSI的物理層規范是有關傳輸介質的特性標準，這些規范通常也參考了其他組織制定的標準。連接頭、針、針的使用、電流、電流、編碼及光調制等都屬于各種物理層規范中的內容。物理層常用多個規范完成對所有細節的定義。
物理層規定了激活、維持、關閉通信端點之間的機械特性、電氣特性、功能特性以及過程特性。該層為上層協議提供了一個傳輸數據的物理媒體。只是說明標準
在這一層，數據的單位稱為比特（bit）。
示例：802.3EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45、fddi令牌環網等。。
OSI是一個定義良好的協議規范集，并有許多可選部分完成類似的任務。
它定義了開放系統的層次結構、層次之間的相互關系以及各層所包括的可能的任務。是作為一個框架來協調和組織各層所提供的服務。
但是OSI參考模型并沒有提供一個可以實現的方法，而是描述了一些概念，用來協調進程間通信標準的制定。即OSI參考模型并不是一個標準，而是一個在制定標準時所使用的概念性框架。
事實上的標準是TCP/IP參考模型
PPPOE機制
另外，還有一個最廣泛的例子就是PPPoE，在以太網上走PPP業務，也沒有用到ARP。它的實現機理是這樣的：我要跟外界通信，首先我發一個PADI廣播包；如果在這個以太網上有PPPoE服務器（即BRAS），那么回復一個PADO單播給我；然后我再發一個PADR給PPPoE服務器請求建立連接，服務器收到后，則回復一個PADS單播包，分配一個SessionID，PPPoE連接建立。
ARP、RARP
1)當ADSL撥號成功時沒有建立IP和MAC的映射。撥號鏈接是一種點到點鏈路，這種鏈路的特點是一端發送的數據總被另一端原順序的接受到。（即使兩端的IP不在同一段上也能夠收到）里面有一個確定性：一定別對端收到；唯一性：一定被唯一的對端收到；順序性：包不會亂續；這樣的鏈路是不需要什么MAC的。
2)你說的撥號可能說的是PPPOE撥號，這個是有IP和MAC的關系的，但使用的而不是ARP協議，而是PPPOE自身的保證機制。這也就是PPPOE能夠防止ARP病毒的根本所在。
如果說道信元的話那是ATM的東西。映射的不是IP和MAC，應該說的IP和VPI VCI對。
任何三層地址都需要映射到二層地址，以太網是IP和MAC，FR是IP和DLCI，ATM是IP和vpi/vci，當沒有映射時，在路由器上debug會看到“encapsulation failed”
有點看不下去了,對于你
3)得出以下結論：
1，如果計算機在訪問internet的時候,不論是客戶機基于以太網，還是服務器基于以太網技術，都必修使用ARP和RARP協議。
2，如果計算機在訪問internet的時候，客戶計算機或服務器都使用FDDI或其他非以太網技術，可以不使用ARP和RARP協議。
最大感覺就是你總結的東西都不對味
簡單的說兩句吧
1.arp和rarp 和以太網之間就是地址解析和反向地址解析協議,是基于以太網的技術,這沒什么好說的
2.如果你非要把 arp和rarp 和internet聯系上的話 這里面的 的關系就沒你說的那么簡單,絕對和狹隘了,internet包含的東西很多,但是和 arp和rarp 有關系的幾乎沒有,這個是你對概念的含糊和理解的不清楚的原因
3.fddi 是光纖類東西,不論是技術還是概念都與arp和rarp 沒關系 那就更不要在說信員是什么了
那么,在最深層次上說, 數據在 以太網 里面傳輸的時候,用到的是模擬信號轉為數字信號 也就是用 0和1來處理數據的電平的
一般說來 arp和rarp 用在內網中就是起到解析地址的作用(以前就是這么定義的,而且這也是最主要的作用) 基本是在設備(pc or sever)端上做處理的 廣義上說可以更本就不用關心他們之間是怎么連的,那就更不需要關心又是什么網絡~
fddi 是光纖傳輸,是將模擬信號轉為光信號來處理傳送的，在兩個局端之間有轉換設備來處理,然后同理也是在另一端復員信號送到局端通過arp和rarp協議來處理數據具體走向的
那么 arp和rarp 和internet的聯系 無論是基于ATM 還是 FR 還是ADSL撥號的 PPP/MP 等等網絡"中間"技術 和arp和rarp的關系簡單來說就一句話,那就是沒聯系,8桿子都打不著
最后 必須這兩個字 在做下結論的時候,在不是很清楚的情況下 最好別用 否則就是在吾人子弟的
多看看書吧
4)ADSL只是種接入方式
5)首先說，我不是什么高手，但是對于你所講的這些東西，自信還有一點了解。
ARP（地址解析協議）和RARP（逆地址解析協議）是某些網絡接口（如以太網和令牌環網）使用的特殊協議，用來轉換IP層和網絡接口層使用的地址。這里已經說的很清楚，arp不是每種網絡都需要的實現。實質上你是可以實現一個二層鏈路完全由非以太網跟令牌環網構成的網絡，這里根本不牽涉arp什么事情。
對于TCP/IP來講，它是可選的，可有可無的。它既不是TCP/IP協議族最初額實現，也不是必須或者必要的實現，如果你不怕麻煩，完全可以不要它的存在（對于RARP協議來講，情況稍微有些特殊）。從這個意義上來講，ARP/RARP根本就沒有追究存在必要不必要的問題。
舉個例子，我們的農業生產什么是根本？種子、土地，人，陽光，環境。除了這些之外，其它的東西就是可有可無的，農業社會，大家是刀耕火種，現在是機械化。ARP/RARP的有無就跟機械化的有無是一樣的。不是必要的，但是現在如果你說不要耕種設備了行不行啊，答案是行，也不行。行是因為沒有一樣可以做，不行是因為現在沒有人再想去面朝黃土背朝天的勞作了，沒有了大家可能真的就不習慣了。
總之來講，討論arp跟rarp存在的必要與否本身，根本就沒有什么意義。
至于什么P2P根本就跟這個帖子的內容沒有什么關系了。說是什么技術，有些牽強。算是一個思想吧，一種軟件組織的架構。至于什么改變互聯網基礎的潛能，讓人聽了卻是摸不著頭腦的感覺。跟之前提的什么C/S,B/S本是一類東西，至于是采用哪種組織軟件，要看應用的特點，并不是萬能良藥，什么東西拿P2P來就萬事大吉，選其它的就不行，反之也一樣。
你的主要問題在于，對網絡實質內容理解本身就膚淺，卻又自以為是。個人認為你需要做的是，靜下心來，認真的理解網絡的實質，不要搞些似是而非的東西出來，這樣真的很誤人的。
6)目前的網絡都有二層的地址，不過不一定叫MAC地址。譬如FR的DLCI,ATM的VPI VCI等等。
下面我們講一個實例化 兩臺電腦的一個通信過程，比如常見的：
HTTP
HTTP協議如何工作？
大家都知道一般的通信流程：首先客戶端發送一個請求(request)給服務器，服務器在接收到這個請求后將生成一個響應(response)返回給客戶端。
1.Request和Response的格式
Request格式：
HTTP請求行
（請求）頭
空行
可選的消息體
注：請求行和標題必須以作為結尾（也就是，回車然后換行）。空行內必須只有而無其他空格。在HTTP/1.1 ? ? ? ?協議中，所有的請求頭，除Host外，都是可選的。
實例：
2.建立連接的方式
HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式為持久連接)。
1) 非持久連接
讓我們查看一下非持久連接情況下從服務器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML文件和10個JPEG圖像構成，而且所有這些對象都存放在同一臺服務器主機中。再假設該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。
下面是具體步騾:
1.HTTP客戶初始化一個與服務器主機gpcuster.cnblogs.com中的HTTP服務器的TCP連接。HTTP服務器使用默認端口號80監聽來自HTTP客戶的連接建立請求。
2.HTTP客戶經由與TCP連接相關聯的本地套接字發出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。
3.HTTP服務器經由與TCP連接相關聯的本地套接字接收這個請求消息，再從服務器主機的內存或硬盤中取出對象/somepath/index.html，經由同一個套接字發出包含該對象的響應消息。
4.HTTP服務器告知TCP關閉這個TCP連接(不過TCP要到客戶收到剛才這個響應消息之后才會真正終止這個連接)。
5.HTTP客戶經由同一個套接字接收這個響應消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發現其中有10個JPEG對象的引用。
6.給每一個引用到的JPEG對象重復步騾1-4。
上述步驟之所以稱為使用非持久連接，原因是每次服務器發出一個對象后，相應的TCP連接就被關閉，也就是說每個連接都沒有持續到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應消息。就上述例子而言，用戶每請求一次那個web頁面，就產生11個TCP連接。
2) 持久連接
非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP得在客戶端和服務器端分配TCP緩沖區，并維持TCP變量。對于有可能同時為來自數百個不同客戶的請求提供服務的web服務器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有2個RTT的響應延長——一個RTT用于建立TCP連接，另—個RTT用于請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。
在持久連接情況下，服務器在發出響應后讓TCP連接繼續打開著。同一對客戶/服務器之間的后續請求和響應可以通過這個連接發送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發送:甚至存放在同一個服務器中的多個web頁面也可以通過單個持久TCP連接發送。通常，HTTP服務器在某個連接閑置一段特定時間后關閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without ? ? ? ?pipelining)和帶流水線(with ? ? ? ?pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應后才發出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，服務器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務器資源便閑置了。
HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個緊挨著發出各個引用對象的請求。服務器收到這些請求后，也可以一個接一個緊挨著發出各個對象。如果所有的請求和響應都是緊挨著發送的，那么所有引用到的對象一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務器發出第一個對象后就不必再以一開始的緩慢速率發送后續對象。相反，服務器可以按照第一個對象發送完畢時的速率開始發送下一個對象。
3.緩存的機制
HTTP/1.1中緩存的目的是為了在很多情況下減少發送請求，同時在許多情況下可以不需要發送完整響應。前者減少了網絡回路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網絡應用的帶寬；HTTP用“驗證（validation）”機制來為此目的。
HTTP定義了3種緩存機制：
lFreshnessallows a response to be used without re-checking it on the origin server, and can be ? ? ? ?controlled by both the server and the client. For example, the Expires response header gives a date when the ? ? ? ?document becomes stale, and the Cache-Control: max-age directive tells the cache how many seconds the response ? ? ? ?is fresh for.
lValidationcan be used to check whether a cached response is still good after it becomes stale. For ? ? ? ?example, if the response has a Last-Modified header, a cache can make aconditional requestusing ? ? ? ?the If-Modified-Since header to see if it has changed.
lInvalidationis usually a side effect of another request that passes through the cache. For example, if ? ? ? ?URL associated with a cached response subsequently gets a POST, PUT or DELETE request, the cached response will ? ? ? ?be invalidated.
4.響應授權激發機制
這些機制能被用于服務器激發客戶端請求并且使客戶端授權。
詳細的信息請參考：RFC 2617: HTTP Authentication: Basic and Digest Access
5.基于HTTP的應用
多線程下載
每個http請求只請求資源文件的一部分：Content-Range: bytes 20000-40000/47000
HTTPS傳輸協議原理
兩種基本的加解密算法類型
通信過程：
優點：
服務器和客戶端交互：
參考文章：http://blog.csdn.net/lisa890608/article/details/8231666
http://www.cnblogs.com/qiqibo/p/3143964.html
http://www.cnblogs.com/skyofbitbit/p/3713125.html
http://www.cnblogs.com/lavenderone/archive/2011/10/14/2212523.html
TPC/IP協議是傳輸層協議，主要解決數據 如何在網絡中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關于TCP/IP和HTTP協議的關系，網絡有一段比較容易理解的介紹：
“我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如 ? ? ? ? ? ?果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也 ? ? ? ? ? ?可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝HTTP文本信息，然后使用TCP/IP做傳輸層協議將它發到網絡上。”
我們平時說的最多的socket是什么呢，實際上socket是對TCP/IP協議的封裝，Socket本身并不是協議，而是一個調用接口（API），通過Socket，我們才能使用TCP/IP協議。 ? ? ? ?實際上，Socket跟TCP/IP協議沒有必然的聯系。Socket編程接口在設計的時候，就希望也能適應其他的網絡協議。所以說，Socket的出現 ? ? ? ?只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而形成了我們知道的一些最基本的函數接口，比如create、 ? ? ? ?listen、connect、accept、send、read和write等等。網絡有一段關于socket和TCP/IP協議關系的說法比較容易理 解：
“TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外的操作接口。這個就像操作系統會提供標準的編程接口，比如win32編程接口一樣，TCP/IP也要提供可供程序員做網絡開發所用的接口，這就是Socket編程接口。”
總結一些基于基于TCP/IP協議的應用和編程接口的知識，也就是剛才說了很多的 HTTP和Socket。
CSDN上有個比較形象的描述：HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網絡通信的能力。
實際上，傳輸層的TCP是基于網絡層的IP協議的，而應用層的HTTP協議又是基于傳輸層的TCP協議的，而Socket本身不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的接口。
下面是一些經常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結。
一。什么是TCP連接的三次握手
第一次握手：客戶端發送syn包(syn=j)到服務器，并進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢后，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉 連接之前，TCP ? ? ? ?連接都將被一直保持下去。斷開連接時服務器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過“四次握手”（過程就不細寫了，就是服務器和客 戶端交互，最終確定斷開）
二。利用Socket建立網絡連接的步驟
建立Socket連接至少需要一對套接字，其中一個運行于客戶端，稱為ClientSocket ，另一個運行于服務器端，稱為ServerSocket 。
套接字之間的連接過程分為三個步驟：服務器監聽，客戶端請求，連接確認。
1。服務器監聽：服務器端套接字并不定位具體的客戶端套接字，而是處于等待連接的狀態，實時監控網絡狀態，等待客戶端的連接請求。
2。客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務器端的套接字。為此，客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字的地址和端口號，然后就向服務器端套接字提出連接請求。
3。連接確認：當服 務器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端 ? ? ? ?確認了此描述，雙方就正式建立連接。而服務器端套接字繼續處于監聽狀態，繼續接收其他客戶端套接字的連接請求。
三。HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。
四。TCP和UDP的區別
1。TCP是面向鏈 接的，雖然說網絡的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實際上也很大程度上保證了）保證了連接的 ? ? ? ?可靠性；而UDP不是面向連接的，UDP傳送數據前并不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接收，當然也不用重 發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2。也正由于1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。
知道了TCP和 UDP的區別，就不難理解為何采用TCP傳輸協議的MSN比采用UDP的QQ傳輸文件慢了，但并不能說QQ的通信是不安全的，因為程序員可以手動對UDP ? ? ? ?的數據收發進行驗證，比如發送方對每個數據包進行編號然后由接收方進行驗證啊什么的，即使是這樣，UDP因為在底層協議的封裝上沒有采用類似TCP的“三次握手”而實現了TCP所無法達到的傳輸效率。
