Skip to main content

[探索 5 分鐘] HTTP 發展歷史

Labels:
為什麼要發明 HTTP ?
HTTP 是全球資訊網 (WWW) 的資料通訊的基礎 !
「全球資訊網」就是 World Wide Web, 就是大家熟知的 WWW, 而 HTTP 就是為了能夠讓資料在這個網際網路流通所訂定的通訊協定。我還有印象, 大學教授曾說中國的狼煙就是最早的通訊協定; 透過煙的顏色, 數量, 來告知遠地的人信息, 把網際網路擴大解釋, 中國是鼻祖 (疑?)。

HTTP 是全球資訊網 (WWW) 的資料通訊的基礎

查詢到「UCLA 舉辦了網際網路的30歲慶生會」這個標題時間是 1999/09/12, 才知道網際網路已經發展將近 50 年了 (1969 ~ 2017 截稿)。

1969 年, 網際網路 (Internet) 之父, 美國 UCLA 教授 Leonard Kleinrock 將 UCLA 與 Stanford 兩個實驗室的電腦, 試連成功
1971 年, Internet 首度連到美國以外地區, 如英國、挪威
1973 年, TCP/IP 通訊協定被提出
1984 年, 美國國防部將 TCP/IP 作為所有電腦網路的標準
1990 年, 英國的 Berners Lee (瑞士粒子物理實驗室) 成功的提出與開發了全球資訊網 (World Wide Web)，被稱為「WWW 之父」
1991 年, Berners Lee 在瑞士歐洲核子研究組織建立了 HTML、HTTP
1990 年 ~ 1999 年間, 網際網路風靡全球, 直到 2000 年網路泡破。
2016年, 有個有趣的事, 美聯社認為「網際網路」已和「電話」一樣成為一件一般的事物, 不具有專屬商標的意義, 於是開始在其格式手冊中規定「internet」和「web」一詞全部小寫, 紐約時報也隨後跟進。今年已經 2017 了, 記得 i 跟 w 都要小寫 !

HTTP 是 TCP/IP 的應用層協定

HTTP 不管從網路 OSI 模型 7 層, 或是 TCP/IP 4 層來看, 都是基於 TCP 層 (傳輸層) 與 IP 層 (網路層) 的應用層, 但事實上只要符合 HTTP 的 RFC 標準, 是可以基於其他傳輸方式來溝通的。參考 wiki 整理下表, 可看出 HTTP 與 TCP/IP 的相對層級。

OSI 7 層
7
應用層
HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP
application layer
6
表現層
XDR、ASN.1、SMB、AFP、NCP
presentation layer
5
會議層
ASAP、SSH、RPC、NetBIOS、ASP、Winsock、BSD sockets
session layer
4
傳輸層
TCP、UDP、TLS、RTP、SCTP、SPX、ATP、IL
transport layer
3
網路層
IP、ICMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、X.25
network layer
2
資料連結層
乙太網、令牌環、HDLC、訊框中繼、ISDN、ATM、IEEE 802.11、FDDI、PPP
data link layer
1
實體層
線路、無線電、光纖
physical layer
TCP/IP 4 層
4
應用層
HTTP、FTP、DNS
application layer
3
傳輸層
TCP、UDP、RTP、SCTP
transport layer
2
網路互連層
IP
internet layer
1
網路介面層
乙太網、Wi-Fi、MPLS
link layer

HTTP 通訊協定的版本

設計 HTTP 最初的目的是為了提供一種發布和接收 HTML 頁面的方法。但今日我們使用 HTTP 協定已經不僅傳輸 HTML 或圖檔, 任何客戶端與服務端透過 HTTP 連線, 發出 HEAD, GET, POST, PUT, DELETE 等請求, 交換文本內容 (text, html, xml, json, jpg, stream...), 都是在進行 HTTP 溝通。而且, 開發的焦點也都是應用行為, 如方法、狀態碼、快取, 已經很少注意底層是 TCP/IP 了。所以當遭遇到為何過多的 request 會造成緩慢 ? 除了網路、過大的資料交換內容、瀏覽器限制,  原來建立 TCP/IP 連線天生就是需要開銷的, 尤其 HTTP 1.1 版本以前不支持持久連線, 那不斷連線斷線, 流量大時可以預見服務器常常忙碌無法回應了。

目前的 HTTP 版本有:

VerRelease
Date		RFCNote
HTTP/0.91991(已廢止),
只接受 GET 一種請求方法
ASCII 電文, 每次斷線重連
HTTP/1.01996/051945可發送多行命令
HTTP/1.11997/012068持久連線被預設採用
1999/062616補充狀態碼
2014/067230
7231
7232
7233
7234
7235		將文件拆為多份:
RFC7230: Message Syntax and Routing - low-level message parsing and connection management
RFC7231: Semantics and Content - methods, status codes and headers
RFC7232: Conditional Requests - e.g., If-Modified-Since
RFC7233: Range Requests - getting partial content
RFC7234: Caching - browser and intermediary caches
RFC7235: Authentication - a framework for HTTP authentication
HTTP/2.02015/057540相容 HTTP/1.1
加入多工 (Multiplexing), 允許瀏覽器在同時間內對多個伺服器發送請求
HTTP/1.1 已經用了 20 年 (1997 ~ 2017 截稿)。2015 年出了 HTTP/2.0 版本估計速度更快, 這邊有個 HTTP/1.1 vs HTTP/2.0 a performance analysis 的評測, HTTP/2.0 快了 60%。也許未來會越來越多站台設計為 optimized for HTTP/2.0, 性能調教上就又多一招了 (但缺點是須建立更多連線減少等待)。

HTTP 通訊範例

打開 command 命令列, 來試試一個 Google 首頁的 HTTP 連線
(注意首頁的 URI 是 / )

 > telnet www.google.com 80
 > GET / HTTP/1.1
    Host: www.google.com

Request

Response

這樣就是一個完整的請求, 而且並沒有馬上被斷線 (HTTP/1.1 特性)。再多試一下 HTTP/2.0 協定看是否有回應。從下圖看起來 Google 首頁也還沒支持 HTTP/2.0 就是了, 而且這個請求馬上被斷線 (Disconnected)。

參考資料

  • https://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE
  • https://zh.wikipedia.org/wiki/TCP/IP%E5%8D%8F%E8%AE%AE%E6%97%8F
  • https://zh.wikipedia.org/wiki/%E4%BA%92%E8%81%94%E7%BD%91
  • https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session
    • https://www.facebook.com/will.fans/videos/1727290680633402/
  • https://www.slideshare.net/WillHuangTW/hypertext-transfer-protocol-77109917
  • https://simular.co/knowledge/site-build/68-about-http2-and-http11.html
  • http://www.infoq.com/cn/news/2014/06/http-11-updated
  • https://www.slideshare.net/LoadImpact/http11-vs-http2-a-performance-analysis

Comments

Post a Comment