tzef 的部落格

web hack post #1

學號:495511569

自從進了資工系以後,最常聽到的問題就是"你能夠入侵XX網站,或破解XXX嗎?"

對他們而言唸電腦的,理所當然要懂這些技能,其實小時候的我也是這麼認為的

人們對於未知的事物總是恐懼的,很多人對駭客都很敬偎,總覺得他們神鬼莫測,能常人所不能,再加上電影的衒染,似乎所有的祕密在這群人面前都將無所遁行,只要他們願意,游走在虛擬與現實,將網撒開,任何機祕彈指間便落網無法逃脫,記得幾年前看過一部電影叫網路上身,直到現在都還印象深刻,片中駭客的能力簡直無法無天,在虛擬網路與實際人生已經密切結合的社會中,高深的駭客彷彿神靈一般掌控一切,全世界有網路的地方都是他的眼睛,連人的身份都能隨意更改,一個念頭就能改變一個人的人生,而整個社會絲毫無法察覺,這麼多麼可怕的能力,希望這種事永遠只存在於電影之中。

事實上任何行業都還會細分為許多領域,所謂外行看樂鬧、內行看門道,資工系唸了四年,從系上各類選修學程還有專題時的題目分項都可看出同為資訊工程,其中滋味可是大不相同,可能有些專精在網路安全的好手,面對win32程式卻不知所措,而像電影裡那般無所不能,五角大廈當成自家廚房進出隨心,腦袋聰明又長得帥氣的駭客在現實中應該是找不到的吧。就像沒有哪一個醫生能夠掌握所有分科,所有的病都會醫一樣,這實在太過不可思議了。

Link Layer 筆記

LinkLayer

        一些名詞定議

        整個網路來看hostsrouters都是nodes,鄰近的兩個node都會有一個實際的link

        link有可能是有線(wired link),無線(wireless link)LANs

       

        Link Layerprotocol data unitframe,是 encapsulated datagram,

        Network datagram 當作 data 目的是將 datagram 由一個 node 傳到鄰近的 node

       

        一個 datagram 可能經過不同 link protocol,每種 link 提供的服務不盡相同,

        可看做是不同的交通工具,可能有的是 rdt ,可能有的就是 unreliable

FramingNetworkLayerIP datagram,加上 headertrailer後轉成frame

MAC

        Media Access ControlAddress,也就是一般所稱的physical address放在frame headers

        identify sourcedestination,這個address是真正機器上網路卡的address,IP的格式不同

LinkLayer同樣要做Flow Control,Error DetectionError Correction

Half-duplex and full-duplex,半多工和多工

Link layer的通常在網路卡上實作,雖然現在越做越小跑到主機版上面去,但運作原理還是相同的

正式名稱叫net work interfacce card(NIC),一般來講叫adaptor,讓網路可以跟主機溝通調節的設備

也可以想成是一個控制protocol的小電腦,裡面有個controller,有記憶體能做儲存,能夠做一些指令

從網路來看是個只管link layer physical layer的東西,再往上層就是軟體負責的部份不歸網路卡管轄

Adaptors 之間的溝通

sending hostreceiving host

NetworkLayerdatagram丟下來

       

  controller

       

sending sidedatagram放到frame裡面去,

加上adds error checking bits, rdt, flow control, etc.

       

receivint host就將動作倒過來,最後再往上丟到CPU

Framing,怎樣將一堆的訊息變成一個一個的單位,通常都會再計算一下framechecksum

最簡單的是Length Count,第一個bit為第一個frame的長度

|5| | | | |    |4| | | |       |7| | | | | | |

1st frame     2st frame      3st frame

另一種Character Flags不同於Length Count用長度,而是用特別的符號

|DLE||STX| data |DLE||ETX|      |DLE||STX|....

¯¯¯¯¯¯¯frame¯¯¯¯¯¯¯¯      ¯¯¯¯¯¯¯¯¯第二個frame

DLE,STX兩個特殊符號當開頭,DLE,ETX當結尾,中間放data

data可能會出現這些特殊符號,解決辦法是在資料兩側多加DLE,

這種extra特殊字元的方法叫做character stuffing

也可以用特殊的一串bit當做分隔

01111110   frame  01111110 frame 01111110 .......

同理當data裡有跟分隔bit相同時用Bit Stuffing,插入0 bit5個連續1裡面

這些規則都是可以自己定的

Error Detection and Correctoin

在無線或是比較舊的protocol裡比較重要,或是要求可靠度比較高的地方

isolated single bit error

burst error,一串bit中間可能有錯也有可能沒錯,會比較複雜

ECC, Error Correcting Code,錯誤更正碼

多給一些空間讓編碼能夠自己修正自己,稱為check bits

m-bits data + r-bits check bits = n-bits codeword

真正的data只有m-bit,由空間和運算來換取安全資料

Hamming Distance(HD),兩個codewords的差異

10001001

  10110001的差異是3,方法是兩個codewordsXOR出來得00111000,1的部份代表不同

Error Correction Theorem

如果要 detect d-bit error,需要distance(d+1)code

假設要偵測3-bit code error,HD編碼必須為4

如果要更正的話,編碼的差異必須是(2d+1)

EDC,Error Detection Code,錯誤偵測碼

EDC= Error Detection and Correction bits (redundancy)

datagram送出去後,再加上EDC,加上一個 redundancy送出去到對方經過一個運算

收到後看原來的資料有沒有相同,如果和運算出來的不一樣那就是detected error

Error Detection通常不是百分之百的reliable,有一個程度的限制,

後面的redundancy越多效果就越好

CRC,Cylic Redundancy Check

一樣是前面的data加後面的redundancy code,CRCredundancy程為CRC bits

裡面有個generating functionR的長度有關,r+1bit,這個長度稱為G

目的是選RCRC bits,DR合起來做運算,D,R合起來能被G2進位運算整除

原有的data D加上R後要整除G就代表OK

假設原來data101110

後面加上redundancy, R bit 3,G就是4,G1001

D乘上2R次方等於二進位後面加30

R = D*2^r/G的餘數

餘數擺在後面等於加上這個值在後頭,接收者再除以G結果整除的話就是OK

同樣R越大或G越長代表越可靠

MAC, Multiple access protocol

link有兩種

        point-to-point,兩點之間直接連在一起

        broadcast(shared wire or shared medium)

                像最早的Ethernet

                上傳的HFC

                802.11 wireless LAN

Multiple Access有一個single shared broadcast channel,然後通時傳輸一堆人

因為同時一次傳向全部,所以必須指定

理想狀況下假設rate R bps

當有M node在傳時平均rate就是R/M,但實際上做不到完全沒干擾碰撞

實務上有三種做法Channel Partitioning,Random Access Protocol跟向CPU schedule一樣用輪流的Taking turns

Channel Partitioning,將整個channel切成很多小塊

        TDMA,time division multiple access

                以時間來分,將一個 frame 分成好多個time slot,每段時間長度剛好夠傳一個packet

        FDMA,frequency division multiple access

                以頻譜分成不同頻段,一樣沒用到的頻段就會被浪費掉,而且頻段間也有可能互相干擾

               

Random Access Protocol

不分割channel,Random Access,是目前用最多的

當一個nodepacketsend,可以使用全部的channel進行傳送,因為無法預測未來

所以必須能偵測collision,並且做到 recover,這中間核心的關念是碰撞後不要立刻重傳,要等待一段delay後再重傳

因為馬上重傳又會馬上碰撞,當然delay的時間不能一樣,不然結果還是相同

MAC照歷史發展可分成三個階段

Pure(unslotted) ALOHA

        傳輸不用對時,想傳就傳,因為frameframe沒有對齊,可能下一個frame跟上一個frame的後半衝到

        導致collition機會增加,任務node成功傳送的機會只有18%

slotted ALOHA

        起源於夏威夷,因為島跟島之間傳輸架網路線很麻煩,只好用無線的

        假設所有frame都是相同size,time切割成相同大小的slots,

                時間足夠傳送一個frame data,TDMA意思相同

                雙方傳送必須在同一個時間,碰撞都可以偵測出來

        實際的操作,node得到frame後就在下一個slot開始傳送

                如果沒有collision,就再把新的frame擺到下一個slot

                collision的話就重新傳送等待幾個slot後再傳

        優點是沒有其他node傳送碰撞的話可以一直傳送下去使用全部頻寬

        壞處是只要一碰撞就會浪費時間跟頻寬

        若有N個節點,任意節點傳送成功機率為Np(1-p)N-1      

        當很多node,最大效率是37%,換言之單一node有超過40%的時間要傳時使用率就會下降

CSMA,CSMA/CD,CSMA/CA

        CSMA,Carrier Sense Multiple Access

                傳輸之前先偵測Carrier,idle的情況才傳,如果正忙碌中就再等一段時間

                一樣會發生collision

        CSMA/CD,Collision Detection

                看訊號的強度可以偵測到Collision後就停止傳送

        現在Ethernet 網路是CSMA/CD

無線網路則是CAMA/CA

另一種MACTaking Turns,大家輪流使用,也有幾種不同方法

Polling

        有一個master node

        其他的node slaves,master一個一個問,不需要的話就再循問下一個

        缺點是master一旦當掉整個線路就停止運作,這個缺點也是client/server最大的缺點

        為了避免single point of failure,現在的server都是一個group

Taking passing

        所有node排成一個環狀,每個node權限都一樣大,有個token會一個node一個node pass下去,

        要拿到tokennode才能傳送資料,傳完後再把token傳給下一個

        一樣會有single point of failure,token斷掉後運作 就停擺了

       

MAC protocols 的整理

Channel Partitioning

        by time, frequency or code

        Time Division, Frequency Division

Random partitioning (dynamic),

        ALOHA, S-ALOHA, CSMA, CSMA/CD

        carrier sensing: easy in some technologies (wire), hard in others (wireless)

        CSMA/CD used in Ethernet

        CSMA/CA used in 802.11

Taking Turns

        polling from a central site, token passing

       

LAN

        networkLayerIP32-bit,用來傳取datagram到目的IP subnet

        MAC address,也叫LAN address physical Ethernet,address,

        總之是網路卡的address,總共48-bit,是網路卡出廠時就做在裡面了

        在同一個區域內的網路傳送用MAC address就行了,不用用到Network layerIP

       

ARP,Address Resolution Protocol,僅能在LAN裡使用,專門用來解析網路上的MAC位址

        經由DSN得到IP,怎樣從IP address得到MAC address就需要ARP來解析

        每個IP node都會有個ARP table,裡頭有IP address,MAC addres,TTL

        TTL,Time To Live,TTL代表ARP table裡的資料經過多久後會消掉(通常設定是20分鐘)

       

        假設同一個LAN的狀況

        host A send datagram to B,如果BMAC address已經在AARP table,那問題就直接解決

        不在的話,A會在自己的區域網路內 broadcasts,這個動作叫ARP query,B收到後就會回應A

        當然Breply就不用像A用廣播的,直接回應給A一個就夠了

        A會把BMAC address裡存起來,TTL時間內要再聯絡B就不用再broadcasts一次

        ARPplug-and-play,隨插即用,不用再做多餘的設定

       

        AB分別屬於LAN 1LAN 2,中間隔了一個router,那就無法用broadcast通知到B,

        當然兩邊的IP address在上層都已經傳遞到了,routerLAN 1裡的node,也是LAN 2裡的node,

        所以router會有兩個MAC address,分別對應LAN 1LAN 2

        實際操作如下

          A creates datagram with source A, destination B

      A uses ARP to get R’s MAC address for 111.111.111.110

        A creates link-layer frame with R's MAC address as dest, frame contains A-to-B IP datagram

        A’s adapter sends frame

        R’s adapter receives frame

        R removes IP datagram from Ethernet frame, sees its destined to B

        R uses ARP to get B’s MAC address

        R creates frame containing A-to-B IP datagram sends to B

        無法直接送給B就先送給router,再由router送到LAN 2,LAN 2收到後從destination裡可以

        知道BMAC address,就由routerAdatagramB

       

        RARP,Reverse Address Resolution Protocol

        早期是為了沒有硬碟的機器,因為沒有Catch來存ARP,所以要透過RARP來取代ARP

       

        ARPmessage結構如下,主要紀錄IPMAC住址的相關資訊

       

Bits

0 - 7

8 - 15

16 - 31

0

Hardware Address Type(16Bits)

Protocol Address Type(16Bits)

32

Hardware Address Length(8Bits)

Protocol Address Length(8Bits)

Operation (16Bits)

64

Sender Hardware Address (first 32 bits)

96

Sender Hardware Address(last 16 bits)

Sender Protocol Address(first 16 bits)

128

Sender Protocol Addresslast 16 bits)

Target Hardware Address(first 16 bits)

160

Target Hardware Address(last 32 bits)

192

Target Protocol Address

ARP MESSAGE

Frame Header

Frame DATA Area

CRC

 

Etherner

        Ethernet中文乙太網路,名聲絕對是如雷灌耳,不管有線無線幾乎吃下整個市場,

        早期的token LANsATM都被Ethernet打得近乎絕跡,speed race10Mbps~10Gbps都有

        目前Ethernet是使用Star topology,即所有點腦都連到一台hubswitch,

        當其中一台電腦斷掉對其他電腦不會有任何影響

       

        Ethernet Frame格式如下,ARPmessage是放在FrameData,IP datagram也在裡面

               

Preamble       

Data Address

Source address

Type

Data

CRC

       

Preamble是一串7bytes獨特的 pattern 來辯別

       

        有一個Promiscuous Mode,這在無線時特別重要,for testing/debugging

        可以讓網路卡接受區網上所有的packets,也常常被拿來做犯罪跟管理

       

        Address6Bytes(48Bits)

       

        Type指出在上面還有沒有更高層的protocol,通常是IP

       

        connectionless,兩個網路卡的連接相連不用像TCP那樣特地去建立連線

        unreliable,因為receiving adapter 收到後並不會有ACK回應,

        雖然直接相連基本上不會loss

       

        protocl是使用CSMA/CD,沒有slots,是為了簡便才不使用對正

        一開始的carrier sense,有人在傳時就不傳

        然後collision detecton random access,要等待一段時間後重傳

        等多久,是重點所在

        實務操作如下

        網路卡接收到NetworkLyaer傳下來的datagram,並建立一個frame

                      

        偵測channel是閒置的就開始傳送,忙碌的話就等待

                       

        順利傳送都沒有其他問題

                       

        察覺到collision,中斷傳送

                      

        中斷後啟動 exponential backoff,中心概念是當碰撞越多次代表越忙碌等待時間就要越長,

        02^(m-1)中間取亂數取一個值,再乘上512bit transmisson times,就是等待的時間回到偵測的步驟

        CAMA/CS http://wps.aw.com/aw_kurose_network_4/ 上有Applet可以看

 

Reaper中文叫中繼器,在長途通信領域,中繼器是一個將輸入信號增強放大的模擬設備,

不考慮輸入信號種類

 

LinkLayer的連結要透過Hub,一開始的Hub就是在physical layer repeaters的加強,只做線的連結溝通

後來功能越來越強才變成switch,如果好幾個網路距離超過100公尺要連起來,就需要一個更厲害的hub連起來

但這樣的連結是沒有必要的,有時候可能只是兩個hub間要溝通,卻將3,4hub集合在一起,徒增collision造成效率低下

發展到後面大部面的hub都已被switch所取代

 

Switch,是用於link-layerdevice,hub功能更進一步

可以store and forward Ethernet frames,可以將收到的frame儲存後再判斷要傳到哪個位置,有點類似router的功能

router看的是IP,switch是看MAC address 再選擇怎麼forward,接送MACprotocol是用CSMA/CD

 

host來說並不知道有這些switch的存在,host而言很簡單的認為只是一個MAC address傳到另一個MAC address

plug-and-play,不需要多餘的configured,能夠self-learning,

因為switch上有buffer能夠store-forward,所以可以允許多個host同時傳給switch,

host來說是一對一不會有碰撞問題,這在原始的dumb hub是不可能的

以前hub只負責線路的傳送,switch需要switch table儲存各個hostMAC address,interface to reach host,time stamp

看起來跟NetworkLayerrouting table很類似,這些table的產生是self-learning,

意思是這些table不用自己去設定,在安裝機器時不用configured,而是在網路卡連上switch時就自己

記下來了,才可以節省下管理的動作,因為對每個hostswitch而言都是一對一,實際操作起來比router簡單多了

switch table

        |MAC|address|interface|TTL|

至於多個switch的連結同樣的原理,self-learningswitch table,沒有hub連結的訊號碰撞問題

 

cut-through switching代表不用完全的sotrforward,如果知道對方是空的就可以先傳送過去

會增加一點效能,這種技術減少了通過交換的延遲,但是降低了可靠性

hub,routerswitch的比較

 

hubs

routers

switches

traffic isolation

no

yes

yes

plug - and - play

yes

no

yes

optimal routing

no

yes

no

cut through

yes

no

yes

switch因為已經接死了所以無法做最佳化

 

Gateway,中文翻譯為閘道

在網路裡可能是個軟體也可能是個機器,主要做protocol的轉換也可以編碼的轉換

用在不同的網路系統格式,ARPAnetsatellite net,ARPAnetinternet的前身

 

ATM網路全名Asynchronous Transfer Mode,是另一套網路系統,下層叫ATM layer,

最下層的data protocol unit53 Bytes ,長度固定其中Header 5 bytes,Payload 48 bytes

剛出來的目的是希望將電腦和通訊整合起來,能夠支持有連接的業務,又能支持無連接的業務

 

MPLS,Multiprotocol label switching,目的是為了將IP forwarding變得更快,

        Ethernet headerIP header中間再加一塊MPLS header

        借用了Virtual Circuit(VC)的關鍵性概念,借用labelforward,而不去check IP address

        因為檢查IP address會比較複雜,

 

       |PPP or Ethernet header|       MPLS header     |   IP header  | remainder of link-layer frame|

                                                               

                        |  lable(20bits) |Experment(3bits) |S(1bit) | TTL(8bits)  |

 

        加入MPLSframe只能在兩台 label-switched router之間傳遞。

        router藉由檢視其forward table中的MPLS label,然後將資料封包交給適當的輸出端來forward MPLS frame

網概10/14筆記

TCP的特點

        point-to-point

                點對點的傳輸,一個sender,一個receiver

                屬於邏輯上的點對點,至於實務上的點對點是在link layer

        reliable ,in-order byte stream

        pipelined

                幫忙flow controlcongestion control,增加效用

        sendreceiver 都有buffer

        full duplex data

                一個connection就可以雙向傳data

                MSS, maximum segment size

        connection-oriented

        flow controlled

                sender不會overwhelm

       

TCP segment structure

        TCP封包格式非常重要,要了解每個欄位的意義才能讀懂截取下來的封包訊息

        裡頭沒有IP address,那是擺在Networkdatagram

        TCP一個packet由兩個部份組成,

        header,紀錄著來源端與目的端應用程式的port,以及相關 sequence number,acknowledgement number,receive window size

        body,紀錄從application傳送過來的訊息,transport稱為segment

       

        TCP介於NetworkApplication之間,對上可接受application所交付的資訊形成TCP資料,
       
對下則將整個TCP封包交給NetworkIP

       

        TCP segment包含的欄位如下

        |<-------------------------------------32 bit--------------------------------------------->|

        |<-------------16 bit------------------->||<----------------------16 bit----------------->|

        __________________________________________________________________-----0 bits

        |                      source port                                     destination port                |

        __________________________________________________________________-----32bits

        |                                                      sequence number                                         |

        __________________________________________________________________-----64bits

        |                                              acknowledgement number                                   |

        __________________________________________________________________-----96bits

        | header  not used         UAPRSF                     Receive window               |

        | length (reserved)          (flag)                                                              |

        __________________________________________________________________-----128bits

        |                      checksum                                         Urgent data Pointer         |

        _________________________________________________________________-----160bits

        |                                              Options(varable length)                                        |                   往上是header

        ________________________________________________________----(160+Option length)bits =(header length)*4*32 bits

        |                                      application data(variable length)                                  |                  ↓往下是body

        ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

        source portdestination port長度都是2Bytes,紀錄TCP兩端應用程式的連接port

       

        sequence numberacknowledge number  這兩個是雙向的,收到就要回傳,所以這兩個會合在一起,在網路上這種附帶夾帶的
        技術叫
diggybacking
長度都是4Bytes,Sequence numberA->BAcknowledge numberA<-B的編號

       

        head length長度固定是4Bits,代表TCP header的大小,size的單位是4Bytes

        舉例來說header length = 0101,TCP header的大小就是 20 Bytes

        TCP header,除了只有Option長度不固定外,其餘欄位都是固定長度,

        換言之TCP header的大小就是取決於Options的長度,Options長度最短為0,

        也就是沒有Options欄位,此時TCP header長度為 20 Bytes,也是header的最小size

       

        not used是保留用途的欄位,長度6 Bits

       

        UAPRSF6bit,每個bit都是一個flag,一個bit代表一個意義

        Urgent AcknowledgmentPushReset Synchronize Finish

        U urgent flag 設為1,表示此封包的資訊屬於緊急資訊,需要立即處理

        A 設為1時表示在Acknowledgement欄位中包含了要回傳過去的確認訊息

        P TCP receiver收到連續性資料時會先放在Buffer,Buffer滿了再一次送給應用程式

                P1,表示send要求receiver立即將Buffer裡的資料傳上去

        R 1時表示立即中斷TCP連線,所有在Buffer裡的資料都會喪失

                通常發生在主動建立連線那端發現port錯誤,或者在資料傳送中出現無法補救的錯誤

        S 代表Sequence Number欄位裡記載的是Initial Sequence Number,表示此packet為連

                線剛建立的第1或第2個封包

        F 1時代表資料已傳送完畢,在中止連線的第24個步驟才會設定此Flag

       

        Receive window 表示Receiver可以接受的流量,長度2Bytes,若忙碌時window會變小

       

        Checksum,長度2Bytes,用來檢查錯誤用

       

        Urgent Pointer,標示緊急資料的指標,Urgent flag1,這個欄位將紀錄在TCP body的資料中,

        屬於需要緊急處理的資料最後一個Byte,例如Urgent Pointer = 3,TCP資料中的前4Bytes

        Urgent資料(0到第3Byte)

       

        Optoins欄位長度不定,可用來擴充TCP的功能,OptionPadding兩部份,

        Padding則是為了使header長度剛好是4Byte的倍數

        Option欄位可細分如下

                Option Kind(8 Bits) Optoin Length(8 Bits) Option Data (長度不定)

                  ↑記錄Option功能的代號  ↑記錄Option的總長度,單位為Byte       ↑記錄Option的資料

                  Option Data長度 = (Option Length - 2)Bytes ,因為KindLength各用 1 Byte

        MSS(maximum segment size)就是TCP常見的一種選擇性功能之一

        主要是在連線要建立時指定所能傳送的segment最大長度,只有當UAPRSF中的S flag設為1

        才會用到此選項,在第1跟第2packet中兩端互傳各自的MSS,那麼接下來每次傳送的TCP segment

        都不會超過這個值

                 

        舉個例子來看sequence numberacknowledgement number這兩個欄位

        Host A 輸入字元'C' 傳給 Host B, Host B收到後再將'C'傳回去

                                        Seq=42,ACK=79,data='C'

                User types 'C'  ---------------------------------->

                               

                                         Seq=79,ACK=43,data='C'

                                        <----------------------------------收到data'C'ACK,並回傳'C'

                                  

                                                Seq=43,ACK=80

    收到data'C'ACK  ------------------------------------>

       

                                                                                       

        A來講前一個收到B傳回來的資料Seq78,下一個期待收到的為79,

        所以傳回ACK=79,data'C'這和ACK,Seq都沒關聯

        A所傳的Seq42,B來講下一個應該要收到43,於是傳回ACK=43,

        AACK=79中告訴B下一個應該送79過去,於是BSeq=79

       

RTT

        TCPRTT裡新增了一個timer,在超出適當的時間後判斷訊息已經漏傳而這個timeout value應該比實際的RTT要再大上一些

        如果跟實際時間比timeout設得太短,會造成premature timeout,對方只是慢了一點就判為timeout重送浪費頻寬,當然設太長
        也不好
,資料早已經丟了還傻傻的在等而
無線網路和有線網路的timeout設定又不一樣

        設定的概念是將過去的RTT時間做一個平均,實際的計算有個公式

        將過去幾次測到的實際RTT平均值RTT乘上一個常數α

        上次剛剛預估的RTT時間乘上(1-α)

        α是0~1之間的一個數(α = 0.125)

        EstimatedRTT = (1-α)*EstimateRTT = α*SampleRTT

        這個公式裡預估的佔0.875,實際的佔0.125,出來就是最新的ExtimatedRTT

        因為timeout要確保真的比RTT還要大,而公式出來的是平均值,這在不穩定的網路中是相當危險的

        所以預估出來的值還要加上一個標準差,給變化做一個緩衝的值(safety margin)

        DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT| (TCP裡設定β=0.25)

        和上一個預估的公式很像,DevRTT是拿上一個算出來的DevRTT和實際RTT與預估值減出來的值合併

        得到的變異數並不是差1,而是4

        所以TCP最後的TimeoutInterval = EstimatedRTT + 4*DevRTT,才是Timeout的設定值

        而α和β的值都是實驗來的,所以並不是百分百保證,總之一定要有個值,經驗越多就越安全

       

TCP裡實做reliable data transfer和之前理論上的rdt類似,有幾項原則

        unrelibleIP之上

        Pipelined segments是一定的,不然效率太低

        Cumulative acks,ACK的回傳是一直加上去的

        TCP use single retransmission timer

                在兩個情況會發生Retransmission

                timeout event

                duplicate ACK

        一開始先假設ignore duplicate,flow controlcongestion control

        產生seq #,開啟timer,設好中止的timeout,timeout到了後就重送並restart timeout

        收到ACK後就看是否第一次ACKOK,如果第二次以上就不對了,代表下面沒有收到

        至於lost的處理或提早timeout的處理都和之前討論rdt時一樣,超過timeout就重送

        而要收到ACKSendBase會往上加,才能續續送新的資料,至於是重送全部還是單一就看是

        GBN還是SR實做而定

       

        接下來是receiverACK時可能發生的情況,TCP RFC建議的實做處理方式

TCP ACK generation[RFC 1122, RFC 2581]

Event at Receiver

TCP Receiver action

Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed

Delayed ACK. Wait up to 500ms

 for next segment. If no next segment send ACK

Arrival of in-order segment with expected seq #. One other  segment has ACK pending    

Immediately send single cumulative ACK, ACKing both in-order segments

Arrival of out-of-order segment higher-than-expect seq. # .Gap detected

Immediately send duplicate ACK,

indicating seq. # of next expected byte

Arrival of segment that  partially or completely fills gap       

Immediate send ACK, provided that segment startsat lower end of gap

Fast Retransmit

        是為了增加效能,有些時候在timeout還未到時就已經知道可以重新傳輸了, 經由重覆的ACKs來判斷是loss segments,因為下一個data已經出去而對方一直回傳上一個ACK,那很明顯就是segment is lost, 所以我們假設收到3ACKs,就是data lost,不用等到timeout, 3這個值也是由實驗得來

       

Flow Control

        receiver side設有Receiver Window來節制Sender不要送太多東西過來, ReceiverBuffer扣掉已經存在Buffer裡剩餘的空間就是ReceiverWindow
     
  RcvWindow = RcvBuffer - [LastByteRcvd -LastByteRead]

        這在課本網站上Applet裡面一樣有動畫可以看到過程

        http://wps.aw.com/aw_kurose_network_4/

Connection Management

        程式裡要initialize TCP variables

        包含要設定sequence numbers

        bufferflow contorl info(ReceiverWindow)這些都要準備好

       

        client端來開始connection,server就準備接收client連過來

        step1

                client sends TCP segmentSYN設為1server

                initial sequence number

                第一個packet是沒有含data

        step2

                server receives接到有SYN flagpacket

                回傳一個同樣SYN1packet,並且initial ACK

                至此兩端的seq.#都設定完成,

                server allocates buffers

        step3

                client receiver SYNACK,

                回傳dataACKserver

       

        closing a connection是比較麻煩的部份

        如果沒好好結束,原來佔用的資源會繼續hold住不放

        step1

                client send一個含FIN值的segmentserver

        step2

                server receives FIN,回應ACK,sends FINclient

        step3

                client收到clientreplies ACK回去

                然後client會進入timed wait狀態

                這個時間大概30秒或1分鐘,並不會馬上結束

                是因為怕回傳的ACK漏掉,如果ACK沒到server就不會做最後關閉的動作

                做為再一層的保障,如果在wait期間又收到FIN,代表server沒收到client之前傳的FIN訊息

                還有機會再送一個ACK過去

        step4

                server收到ACK後將connection 完全關閉

               

Congestion Control

        是中間網路環境的問題,而非兩端點的問題, 當太多使用者送了太多data時就會造成網路的塞車

        當網路中間堵塞時可能會

        lost packets(buffer overflow at routers)

        long delays(queueing in router buffers)

        處理方法一般來講有兩大類

        End-end congestion control

                兩端點做自我的節制,client由資料的遺失來判斷堵塞情況

        Network-assisted congestion control

                router提供一些 feedback 訊息

                真的將網路狀況反應回去,sender就能做傳送的節制

TCP Congestion Control

        TCP因為沒有回傳網路狀況的設計,所以堵塞的控制完全是靠兩個端點

        sender送多少要看congestionWindow而定,

        rate = CongWin/RTT (Bytes/sec),單位時間內所能傳送的資料量

        timeout或有3 duplicated acks,

        如果不減小Window,也可以sender reduces rate

        處理的方式

        AIMD,additive increase multiplicative decrease

                慢慢增加能承受的CongestionWindow,慢慢測試最大忍受值,一旦感覺到擁塞就立刻下降一半(ex.18->6),再慢慢加直到發生狀況再降下來, 實務上不大用這個機制,增加得太慢太保守了

        Slow start

                AIMD一樣從小加上去,但是是以平方加上去(2->4->8...)

        如今TCP Congestion Control的處理方式

        CongWin低於Threshold時以Slow start方式加上去

        超過Thresholdsender進入congestion-avoidance狀態,改成以線性方式增加

        當收到3個重覆ACKThreshold設成1/2,CongWin設成新的Threshold

        timeout發生時Threshold設成1/2,ConWin設為 1 MSS

Throughput

        TCPaverage throughput速度是透過一個function利用window size and RTT所計算出來

        windowWthroughput = W/RTT,當W減少為W/2,throughput也會跟著減少為W/2 PTT

        目前經過計算Average throughout0.75W/RTT

TCP Fairness

        TCP到底公不公平,可能一邊節制了另一個使用者的連線卻沒有做節制

        當沒有UDP在時TCP是公平的,有相同需求的兩端會在bandwidth share附近震蕩

        兩邊互相影響下是公平的

        但是UDP在的話就不太公平了,因為多媒體不用TCP而且講究順暢,事實上因為不節制的話對網路

        傷害太大現在像youtube會在UDP上加上一些TCP friendly,避免影響到其他使用者的應用

        早期的瀏覽器可以設定要同時開幾個TCP connection,當要求越多TCP connection 速度就越快

        這樣對其他使用者就不公平了

Delay modeling

        一般來講不看congestion的話,建立connection的時候,data transmission delay,

        一開始slow start慢慢開始的時候也會delay

       

網概10/7筆記

Transport layer

上面是application layer,下面是network layer,是端點對端點的,中間是logical end-end transport,不管中間經過幾個router,delay如何,這些都交給下層處理不是應用只是提供給application layer的平台

       

Transporprotocol data unit叫做segment,都是同樣的概念只是名詞變了而已,applicationmessage切成segment,從自己這台電腦送到自己下面的network layer,而另一端從network收到後再組成application message,

Internet上兩大 transport protocolTCPUDP,視不同應用決定哪個protocol

       

Transport layer和下層Network layer的比較

Network layer是每個hosthost直接溝通,或是機器和router之間,Transport layer則是屬於process之間,從作業系統看每個application的程式到transport layer裡面都是一個一個的process,建立一個一個的connection,Transport是兩個端點之間的process的聯絡,application則是兩個應用程式間的聯絡,application只是兩個應用程式,下來transport可能就變成一堆的processconnect

 

TCP要擁有reliablein-order delivery必須要做到以下幾件事

        congestion control,網路狀況不好時要做些節制

        flow control,先到先到後送後到,漏掉的要補起來

connection setup,要建立和結束connectionTCP中很重要的一個動作,UDP相對TCP來講是unreliableunordered,當然當下層狀況良好時也不一定是unreliable,UDP基本來講只是做IP的延伸,抓到datagram就送出去不管是TCPUDP,下層的network layer都是IP,不管是哪一個都不保證delay guaranteesbandwidth guarantees,都只是盡量做,不保證傳送在多少delay內達到,傳送的頻寬也無法保證,要保證是在下層的技術來做,下層保證了上層自然保證,但只以Transport來講是無法做保證的

 

Multiplexing and Demultiplexing (多工與分工)

        傳送好多個socket時做Multiplexing的動作,

        收到好多個socket則做Demultiplexing的動作

 

Demultiplexing work

hostnetwork layer收到IP datagram,每個datagram都會有一個source IP address,hostdestination IP addressport number就能知道要送到哪一個socket

 

        UDP的話是connectionless demultiplexing

產生一個datagramsocket,當然一個host可以開好幾個data socket,每個socket是由IP addressport所合起來的,才能連結到對方收到UDP segment ,check destination port number,將這個segment指到那個port上面的socket如果一個IP datagram有不只一個IP address, source port number,都有可能directed到同樣的socket

 

當兩個socket連到一個同樣的process,同樣的socket,兩個clientsource port都相同,這時server只能用HTTP cookie和應用的session來判別同樣的socket進到同樣的port,server要傳出去時因為已經知道兩邊clientdestination port,就能從同樣的socket往不同的目標而去,在傳送進去的時候就已經知道回去的原路了

 

建立TCP connection需要四個條件

source IP address

source port number

destination IP address

destination port number

之後就不需要將IP address擺在裡頭

clientsource port連到serverdestination port,假設client IPA,server C,連線建立後進到serversocket,process回應連接OK,其餘的connection建立也都相同原理

 

UDP

        User Datagram Protocol

協定在 RFC768

傳輸有可能失誤

不建立connection,沒有handshaking

雖然不可靠但負擔比較小, 也不用花時間建立connection

通常用在stream multimedia,這些可以忍受損失但必須盡快達到,速度比檔案的完整更重要

DNSSNMP都是用UDP

SNMPSimple Network Management Protocol,網路管理需要節省資源給真正需要的應用如果需要可靠的傳輸可以在UDP上自己做check

 

source port      destination port

 __________________

  length               checksum      

 __________________

    Application data(message)       

                                               

  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

UDP segment format,sourcrdestination port是絕對必須的,lengthUDP segment的長度,包含header,socket裡有寫傳到哪台電腦,UDP segment還要再往下傳到neswork layer,再包裝加上senderreceiderIP address,所以在這裡不管portIP,至於checksum是用來偵察error的存在,確認內容在傳送的過程 有沒有被更改過,error的產生有人為跟非人為都有可能

 

checksum的運作方法是將segment contents當作一個16-bit的整數

                       

        將整數取1的補數(1's complement)

                       

        將數值存到checksum

                       

Receiver將收到的資料再做1's complement

                       

        checksum做比對

                       

        如果不同就是error

       

其他的check還有ParityCRC(Cyclic redundancy check),checksum屬於比較舊的技術,網路上比較常用的是CRC,但不管哪個共同目的都是把原來資料經過運算得到一個比較短的資料,另一端接收到後再運算一之做比對確認資訊有沒有異常

       

Rdt

        Reliable data transfer

        進化的過程是

        版本從1.03.0

        加入pipeline的傳輸

        要看Go-Back-N(GBN),就是傳錯要回頭

        要看Selective Repeat(SR)

       

        這些不只用在transport layer, aplication layerlink layer都很重要

       

        基本原理

       

        Application

        layer                        sending process                  receiver process

        _______________________data__________________data__________

        Transport layer                       reliable channel

                                                         

       

有一個送出端有一個接收端,送出端裡面有一個sending process,有一個receiver process,application layer看起來data傳出去到下面一個reliable channel,如果channel是可靠的,那麼application接收到的自然也是reliable,如此的話當然就不用管什麼rdt了但實際上的網際網路下面都是unreliable channel,其中出問題的原因非常多可能太多人一起使用,軟體設計,硬體問題等各種原因,一定會有問題存在rdt就是要研究中間要怎麼送才能做到reliable的傳輸,就是下面雖然不可靠但要讓上層覺得是可靠的至於中間不可靠的原因就要想辦法處理掉

       

        Application layer呼叫rdtsend,TCP建好socket確認好就開始傳送         

        _________________________________________________________________

                   rdt_send()  |data|               |data|  deliver_data()

                   ________________       __________________

        send   reliable data              reliable data    receiver side

          side  transfer protocol       transfer protocol   

                   (sending side)          (receiving side)

            ¯¯¯¯¯¯¯¯¯¯¯¯↑¯¯¯¯¯¯              ¯¯¯¯¯¯¯¯¯↑¯¯¯¯¯¯¯¯¯

               udt_sent()|packet|                |packet|rdt_rcv()

                                           __________________

        packet傳送出去                  reliable channel            接收到後要檢察檔案是否

        經過reliable channel          ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯                完整正確,否則就重送或者等待

       

        rdt1.0

        1.0是最簡單的想法,假設沒有bit errors,也不會有packet loss,Finite State Machine(FSM)來看senderreceiver都只有一個狀態

                                                              

      |等待上層|_ 將從application收到      |等待下層|_ 將從transport接到

      |呼叫傳送| |的data轉成packet         |呼叫接收| packet extracedata    

      ¯¯¯¯¯¯¯¯↑¯  |傳下去                          ¯¯¯¯¯¯¯¯↑¯ 

       sender  ¯¯¯¯                                    receiver ¯¯¯¯

 

        rdt2.0

可能會有bit error,就是0變成1,1變成0,可以用checksum來偵察bit error,除了檢查是否有error外還需要有回應的機制ACK(acknowledgement),回應有收到或沒收到

        NAK(negative acknowledgement),有收到,但是有錯誤 重送

        FSM來看,receiver1.0時一樣是一個state,檢查checksum後回傳ACKNAK

        sender則有2state,第一個state1.0不同的是一開始的data必須加上checksum才轉成packet

        packet傳送出去後狀態不像1.0回到等待傳送,而是等待receiver回應的ACKNAK,

        收到ACK後才能回到狀態一繼續等待傳送,若是NAK也不用回到wait的狀態,就直接重新再傳送一遍

        乍看2.0似乎很完善,仍有個問題就是但不可靠的channel也可能會使NAKACK訊號出現錯誤,

        sender會不清楚是否該重送,如果上次傳送沒問題sender卻重送一次將產生duplicate,

        就是同樣的檔案有兩個,所以必須加上sequence number在每個packet上避免混淆,receiver才知道丟掉重覆的檔案

       

        rdt2.1

        為了解決2.0隱藏的問題,2.1sender有四個狀態,packet除了datachecksum外還加入了sequence number

        也就是所謂的序號,sequence number當然不可能無限制的加大下去,通常有個範圍過了後就從頭計算

        3.0sequence number01來解釋,packet可分成兩種,一個是加上sequence number 0packet,另一個就是1

       

                                等待傳送序號                                       等待receiver          -----如果是NAK

                                0 packet        ---------------->      回傳的ACK NAK      <--------重新傳送

                                                                                                    |

                                        | ACK                                                     | ACK

                                        |                                                           

                     NAK     等待receiver                                          等待傳送序號

                      |_______回傳的ACK NAK      <--------------            1 packet

               

        receiver分成等待 sequence 1 packet sequence 0 packet

       

               

          ______________________           checksum正確,packet                   ______________________       

          |檔案出錯,回傳NAK |              extrat後傳到application                    | 檔案出錯,回傳NAK

          |等待sender重新傳送              並回傳ACK sender                            等待sender重新傳送

           ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯等待packet 0 -------------------->等待packet 1 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

                                                               <--------------------

       

另外有一種可能是等待packet 0卻收到packet 1,這代表前一個packet很可能漏掉了這時就回傳一個ACKsender重送上一個packet

       

        rdt2.2

        其實NAK是可以拿掉不用的,一個ACK就夠了,receiver收到OK才回覆,

        OK就不用回覆了直接由sender用其他機制自己決定

        先前的ACK都沒有加上編號,收到同編號的ACK視同NAK

       

        sender一樣在傳送完packet 0 後等待ACK 0,如果收到ACK 1就再重送packet 0,

        等到ACK 0 確認傳送OK後就進入傳送packet 1的狀態

       

        receiver這邊同理在等待0的時候如果收到packet 1,代表先前收到packet 1時回傳的ACK 1 sender可能

        沒收到,就再回傳一次ACK 1,sender就會送下一個packet 0過來

       

        rdt3.0

之前考慮的都是data error的狀況,3.0替不穩定的channel多考慮了loss的可能性解決的辦法就是加入一段限制時間,假設超過時間還沒收到就是傳送時漏掉了而這段時間多少才算合理也是一門學問,如果時間設太短,或是data 只是 delay長了點並沒有loss,就會造成資料的重覆,回傳的ACK也有一樣的問題,所以兩邊都要有sequence number

       

        3.0sender多了一個timer的設計,一送出去就開始計時,時間內收到ACK的處理都和2.2相同,restart timer

        開始傳送下一個data或是重新傳送,如果時間內沒收到ACK則視同ACK錯誤,restart timer然後重新傳送

       

        前面是以FSM來解釋,比較跟分析,現在以時間軸來看實務上的操作

        ----------------no loss no error------------

                  sender         receiver                  

               

                send pkt 0                                                               這無疑是最完美的情況

                                                                                            sender送完paket 0

                                                rcv pkt 0                                  receiver也成順利的接收

                                                send ACK 0                              並回傳ACK 0

                                                                                            sender順利收到ACK 0

                rcv ACK 0                                                                 接著送paket 1

                send pkt 1                                                                時間軸很順的一直推下去都沒有問題

                                       

                                                rcv pkt 1

                                                send ACK 1

                                                                                   

                rcv ACK 1

                send pkt 0

                                       

                                                rcv pkt 0

                                                send ACK 0

                                                                                   

                                       

        ----------------lost packet-----------------

                  sender         receiver                  

               

                send pkt 0                                                               這裡在send paket 1

                                                                                            出現一次loss

                                                rcv pkt 0                                  在超出限制時間後

                                                send ACK 0                              serder判斷上一個paket漏傳

                                                                                            重新傳送後receiver順利接收

                rcv ACK 0                                                                 然後回應ACK 1

                send pkt 1                                                                loss packet的情況順利解決

                        |             

                        |                      X(loss)

                timer             

                        倒數               

                        |             

                        |                                             

                timeout

                resend pkt1

                                       

                                                rcv pkt 1

                                                send ACK 1

                                                           

                rcv ACK 1

                send pkt 0

                                       

                                                rcv pkt 0

                                                send ACK 0

                                                   

                                       

                ----------------lost ACK-----------------

                  sender         receiver                  

               

                send pkt 0                                                               同樣,ACK也有可能會loss

                                                                                            sender一樣有timer倒數

                                                rcv pkt 0                                  在傳送完paket 1

                                                send ACK 0                              sender在等待receiver回應的ACK 1

                                                                                            ACK在傳送出已經漏掉

                rcv ACK 0                                                                 timeout後因為沒收到ACK回應

                send pkt 1                                                                sender無法繼續送下一個packe

                        |                                                                  sender不管是packet loss還是ACK loss

                        |                      rcv pkt 1                                  重新傳送一次packet 1

                timer                     sen ACK 1                                這次receiver就收到兩次packet 1

                        倒數                                                            出現兩個重覆的data

                        |        x(loss)                                                  所以receiver要處理掉一個duplicate

                        |                                                                      然後回傳ACK 1將傳送繼續下去

                timeout                                                                  

                resend pkt1

                                       

                                                rcv pkt 1

                                                detect duplicate

                                                send ACK 1

                                                           

                rcv ACK 1

                send pkt 0

                                       

                                                rcv pkt 0

                                                send ACK 0

                                                   

 

                ----------------premature timeout-----------------

                  sender         receiver                  

               

                send pkt 0                                                               time值沒設好或網路delay太嚴重時

                                                                                            就可能會有將delay誤判為loss的狀況發生

                                                rcv pkt 0                                  在傳送完paket 1

                                                send ACK 0                              sender在等待receiver回應的ACK 1

                                                                                            ACK 1只是因為網路太慢遲到而且不到

                rcv ACK 0                                                                 timeout後因為沒收到ACK回應

                send pkt 1                                                                sender判斷有資料loss

                        |                                                                  重新傳送一次packet 1

                        |                      rcv pkt 1                                  這次receiver收到兩次packet 1

                timer                     sen ACK 1                                receiver要處理掉一個duplicate

                        倒數                                                          然後回傳ACK 1準備將傳送繼續下去

                        |         delay                                                 但這時剛剛遲到的ACK 1才送到sender

                        |                .                                                   sender不知道這個ACK 1是遲到的ACK

                timeout             .                                                   sender在送出paket 0又會收到一個ACK 1

                resend pkt1                                                        是因為timeout重送pakget 1,reciver回應的

                                                                                     但因為sender已經送過paket 0,

                                          rcv pkt 1                                  正在等待的是ACK 0的回傳卻收到ACK 1

                  rcv ACK 1             detect duplicate                      sender視同錯誤,再重新傳送paket 0

                  send pkt0       send ACK 1                              造成receiver又一次的duplicate

                                                                                        處理完成後繼續正常傳送下去

                rcv ACK 1           rcv pkt 0

                send pkt 0                  send ACK 0

                                         

                                          rcv pkt 0

                                          send ACK 0

                                                                   

 

        rdt3.0看似OK其實效能很差,舉個例子

        假設 1 Gbpslink(1G = 10^9 bit/s),end to end propagation15 ms,packet大小 1KB(1Byte=8bit)

        Tramsmit時間 = packet length/transmission rate(bps)

        L/R = 8kb/10^9b(sec) = 8 microsec

        RTT = 2*e-e prop = 30ms

        sender真正傳送只需要0.008,但必須等到封包回來才能傳送下一筆,

        而這段等待的時間加上傳送時間是30.008

        使用率只有0.008/30.008 = 0.00027,非常的低

        sender絕大部份的時間都在等待

        問題出在rdt3.0 protocolstop and wait,即送出去後要等待對方的回應才能進行下一步動作

        這個例子可以看出來protocol設計的不好,不管資源多好都會被浪費掉

        要有效率一定要做到pipelining,尤其是長距離的傳送越顯重要

        rdt3.0前最重要的問題是因為網路的不穩造成資料的error,pipelining雖然效率提升,但也必須要有自己

        一套機制來解決問題

       

        Go-Back-N(GBN)

        3.0前的sequence number都是01,真正的sequence number都會比較大一點,5-bit,67-bit不一定

        pipelining雖然可以一直送,但也要考慮接收者的頻寬承受能力

設一個windowN的最上限,假設對方最大承受是10,那就先送10,等收到ACK確認對方消化掉後再send後面的資料

        在兩邊的溝通上做個調節

另一個改進的方式是 cumulative ACK,收到資料不需要每個packet都回應ACK,因為pipelining是一次傳送一大堆的資料,receiver再一次回應一大堆ACK其實是沒有必要的,假設收到12345就傳最大的5回去就好如果某個sequence number一直沒收到就在number之後的資料全都重送

        假設pipelining一次送了12345678出去,在傳送中4漏掉了,ACK回最大的3回來,

        那麼sender就回去最後一個收到的ACK開始重送,也就是從45678開始

        課本網站上有個動畫可以清楚看到Go Back n的過程,Applet裡面

        http://wps.aw.com/aw_kurose_network_4/

       

        GBN很明顯有一個問題就是重複性太高,在漏掉的packet後已經傳送的資料就全部丟掉再傳一次

        另一個機制是Selective Repeat(SR),只將漏掉的部份重新傳送,但要做到這點必須每個packet

        ACK回傳,網站上一樣有動畫解釋

       

網概9/30筆記

FTP

        the file transfer protocol

       

協定在 RFC 959    

port:21

        FTP是一個把controldata connection分開的protocol

        一個connection專門傳命令,一個connection專門傳data,data connection

       

      FTP   --- TCP control connection by port21-->  FTP 

     client  <-- TCP data connection by port 20----- Server

 

        所以一邊傳資料還可以邊下指令,像看檔案目錄等

        這種controldata connection分開的設計叫out-of-band,HTTPin-band

        HTTP不同,FTP就算檔案傳輸結束,control部份仍然保留,可以繼續交談

       

        常見Server回傳的status code

        331 Username OK, password required

        125 data connection already open; transfer starting

        425 Cant open data connection

        452 Error writing file

 

SMTP

        Simple Mail Transfer Protocol

 

協定在 RFC 2821

port 25

        Electronic Mail專用的協定

        使用者先有一個mail帳號,登入到mail Server

        傳遞是mail Servermail Server間傳遞,client端再用user agent(Outlook)讀取

        mail Server即是client也是server,mail的時候是server,送的時候就是client

        過程:handshaking->transfer->closure

        A->user agent->mail serverA-->>mail serverB->user agent->B

       

        uses persistent connection

        指令都是ASCII text

                一開始ServerClient先互傳HELO,確認連線

                接著MAIL FROMRCPT TO,ServerX要寄給ClientY,雙方互相確認OK

                開始DATA傳送

                . (end of message)

                QUIT結束connetion

               

        request message7-bitASCII

        server訊息以CRLF.CRLF 表示end of message

        CRLF:換行

       

        HTTP的比較

                HTTPpull

                SMTP mail serverserver間是push,client端使用者上去抓信件是pop

                commandresponse interaction, state codes 都是ASCII

MIME

        multimedia mail extensions

 

協定在 RFC 2045,2056

        web上接送多媒體訊息

       

        From: alice@crepes.fr

        To: bob@hamburger.edu

        Subject: Picture of yummy crepe.

        MIME-Version: 1.0                                       →表示下面開始傳送的東西將不是文字

        Content-Transfer-Encoding: base64               →下面送的東西以base64方式編碼

        Content-Type: image/jpeg                            →將圖片編碼,因為不編成ASCII無法放進body傳送

       

        base64 encoded data .....

        .........................

        ......base64 encoded data

        multimedia data

       

Mail access protocols

        useragentmail server抓郵件的協定

        POP

                Post Office Protocol [RFC 1939]

                常說的POPPOP3,當使用者要去某個mail server讀郵件時,自己透過Outlook等讀取,

                必然會經過authorization,連接mail serveragent,才能用軟體download下來

                POP3的過程

                        S: +OK POP3 server ready                    

                        C: user bob                                         

                        S: +OK                                                |→authorization phase

                        C: pass hungry                                       認證的部份

                        S: +OKuser successfully logged on          Serverresponses只會有OKERR兩種

                                                                                    接下來就是傳輸的部份,FTP有點像,都是抓檔案下來

                        C: list                                                       →訊息目錄                                                   

                        S: 1 498

                        S: 2 912

                        S: .

                        C: retr 1                                           →接收信件

                        S: <message 1 contents>

                        S: .

                        C: dele 1                                          →刪除信件

                        C: retr 2

                        S: <message 1 contents>

                        S: .

                        C: dele 2

                        C: quit

                        S: +OK POP3 server signing off                      

        IMAP

                Internet Mail Access Protocol [RFC1730]

POP更進一步,除了download郵件外還可以在server上管理目錄,可以做更多的動作,  像郵件目錄的搬移等都得靠IMAP

        HTTP

                Hotmail, Yahoo Mail

       

DNS

        Domain Name System

        網路上名字跟地址要分清楚

        地址是IP address(32bit),但人們通常用name(ex. www.yahoo.com)

        name轉譯到address上就是DNS,專門做nameIP address的翻譯

        distributed database

資料是分散式的存儲,Internet一開始設計的概念就是分散式,不把所有東西集中在同一個地方,設計是 hierarchy of many name servers,name server是階層式存在的,用資料結構的講法就是樹狀的name server所組成的檔案儲存資料庫,屬於application-layer protocol, host,routers,name server互相溝通參與,目的是將nameIP address解出來是核心的internet function,也是application-layer裡的一個protocol

       

                                 Root DNS Servers

                                                          

com DNS servers             org DNS servers              edu DNS servers

                                                                                               

yahoo.com      amazon.com          pbs.org                      poly.edu           umass.edu

DNS servers     DNS servers           DNS servers                DNS servers       DNS servers

 

amazon為例,client 提出 www.amazon.com,會先找到comDNS server,然後從裡面取得amazon.com serverIP address,但拿到amazon.comDNS server IP address後只代表找到amazon.comname serverIP,amazon內還有一堆的IP跟一堆的name,所以還必須queries amazon.comDNS server找到真正想找的IP addresing

 

目前全世界有13root name server,root往下是Top-level domain(TLD) servers,com,org,net,edu等再往下是Authoritative DNS servers,就是各組織,公司各自的DNS server取得IP的做法有很多種

iterated query:

        local name server是直接面對自己主機的name server,host想找某個nameIP時會先問local DNS server,不在範圍內的話

        會救助於root DNS server,然後root會回應要到哪個TLD DNS server尋找,TLD再告訴local要到哪個authoritative DNS server,

        最後再取得IP

recursive query:

        差別在root server不把TLD server回給local,直接順著傳到TLD,同樣TLD也不會回local,等最後的IP取得後    再順著原本的路徑回給host

http://wps.aw.com/aw_kurose_network_4/

網站Applet裡有詳細的動畫,看了後會清楚許多

       

DNS records儲存的格式稱為RR(distributed db storing resource records)

        RR format: (name, value, type, ttl)

 

 

P2P

P2P有很多應用,大多數人了解的都是檔案分享,每一個Peer即時client也是server,P2P有很多形式,最早期的是Napster,存在一個centralized directory,PeerPeer要連結時必需先跟    centralized server先連結一下,再由server通知哪些Peer有使用者所尋找的檔案,先用server溝通,接下來的傳輸才是P2P,缺點是將所有資料清單都擺在同一server,風險太大,而且這家公司最後因版權問題倒閉

       

另一個Gnutella是完全分散式的P2P,是一個overlaynetwork,就是在一個網路上再架一個網路,兩個Peer間是用TCP來連結,設計上一個Peer不能有太多的neighbors(<10),當然跟每個機器的能力不同也有關,因此產生了一個問題就是將全部都看得太平等,Peer眼裡看不到全世界,也沒有server,只有附近的neighbor,要檔案時只能透過neighbor一層一層找下去,直到找到再傳回訊息,為了避免message無限制亂傳下去,需要加入時間的限制否則會形成一種現像叫flooding,乍看之下很有效率,但當大家都有這種需求時,不管有沒有Hit都是一件很混亂的事,P2P的現像是一開始抓到一個點,Peer joining,建立TCP連線後開始發送ping訊息,回來的訊息叫pong,再跟回應的pong message建立連線,work分散到各個node,在時間上比cline/server節省

       

另一個P2P形式是BitTorrent,tracker是追蹤參與的Torrent,一開始負責取得peerlist,Torrent是由從檔案切割成很小的chunks組成,Gnutella不同的是BitTorrent將資料做切割成256KBchunks放在各個Node,整體效率會往上提升,在下載的同時peer也同時將chunks上傳到其他的Peer,全部載完後可以選擇留下來繼續貢獻,下載的規則是從最少人有的chunks優先request下載,以確保種子檔案的最佳完整,至於上傳則是以之前給 chunks最多,速率最快的Peer優先,這個設計是為了克服人性並鼓勵做種上傳

       

Skype,也是P2P但應用是在VoIP(Voice-Over-IP),Skypegroup readerSupernode,很多Supernode都是Skype買來建置的,為了要在打電話時先確認對方是否在線,必然需要一個login server,making calla時加入一個Supernode的網路裡面,flooding的方式一個node一個node找下去所有P2P都分兩個部份,第一個部份是 Search,怎樣去找到Target,指要尋找的檔案或要聯絡的人,第二個是找到後就直接連接,至於中間的連線好壞就是更下層的事情了,所以大部份的力氣都是花在尋找上

 

Socket programming

socket是一個APIinterface,要做clinet/serveroperation,或是P2P都可以用socket來寫在1981BSD4.1 UNIX裡開始被提出來,是一個host-local,application-created,OS-controlledinterface是一個programming標準的介面,OS眼裡是兩個process分別在兩台機器上怎麼來收送message,

寫法分TCPUDP兩種

        TCP connection的建立,需要IP addressing,port 和可同時接收幾個connection的限制參數

serverprocess一定要先run,然後create一個socket, client端的process才能透過serverIPport連上去,通常幾個client連過來,server端就建立幾個Thread,socket最因難的地方就在於這些thread的同步問題大部份的程式都要和IO stream接連,就是一個資料流,先進先出後進後出的steam,一個process通常會有兩個stream,一個input一個output stream,keyboardinput stream,可是網路這邊是output stream出去,       從網路回來時對client process來講又是input stream,input streaminput process,ouput就和output process連一個process裡又有input又有output,IO間的關係需要特別注意清楚

UDP 來講不建立connection,不需要handshaking,所以傳送的data有可能會lost掉和TCP不同,TCP是有來回後才建立connection,UDP送一個datasgram後就不管了,所以傳送的順序和可靠性都不受保證,UDP每次的傳送都帶著IP addressport,TCP因為已經建立好連線就不需要帶著這些資訊

       

網概9/23筆記

Packet Switch

        沒有建立線,資料切成一段一段的packet

       

router 停下來儲存了再傳

delay = 3L/R (s)

L(bits)頻寬

R(bps)速率

 

circuit switch 頻寬被佔用,不用就沒有用了

packet switch 可以容許多一點的人傳

packet switch 整體效率比circuit switch

 

great for bursty data

bursty data 指非連續的資料

packet會排成queue,array超過頻寬時就會queue起來排隊(FIFO),排不下時就loss       

第一個delay

        nodal processing,從進入router到進入排隊,typically a few microsecs or less

第二個delay

        queueing,depends on congestion

第三個delay

        Transmission delay

                R=link bandwidth(bps)

                L=packet length(bits)    

                time = L/R       (資料量大小/頻寬)

第四個delay

        propagation delay,跟真正的距離有關,a few microsecs to hundreds of msecs

        訊號傳遞的距離

                d=length of physical link

                s=propagation speed in medium(2*10^8 m/sec)<光速>

                propagation delay = d/s (距離/速率)

Nodal delay =

        processing delay = queuing delay = transmission delay = propagation delay

 

traffic intensity = La/R(無單位), a = average packet arrival rat

La/R 越大代表 traffic intensity強度越大

->0 delay small,即頻寬很大或資料很少]

->0 delay become large,準備開始排隊,進來的量和出去的量差不多,理想狀態

>1  more work arriving than can be serviced,delay infinite

                lost一些packet,代表queu越來越長超過極限

 

Traceroute program:provides delay,可以測試delay狀況

 

throughput:rate(bits/time unit)

        就像水管粗細,若一個水管細第二個粗OK

        反之則產生一個瓶頸,可將整個internet看成一個大水管,很多小水管匯集而成

       

Protocol Layers

        歸類切成一層一層的層次

        不同的層次看對方的層次,以瀏覽器跟web server來講,這個軟體跟那個軟體溝通

        中間下面的層次就不用看,只做web的話下面的layer就不用看

       

        reference model中最有名的是ISOOSI model,實際用的是internet model,

        參考的時候看OSI model,分一個一個的層次,有模組化,對維護、更新改進就更加容易

       

        課本中分五個層次

                application

                        FTP,SMTP,HTTP

                transport

                        TCP,UDP

                前兩個層次是上層,端點對端點,真正連是在下面的網路

 

                network

                        IP,routing protocols

                link

                        PPP,Ethernet

                        routerrouter間的那條線

                physical

                        真正的bits

                       

網概裡在Applicationtransport layer中殺掉了兩個layer,以前學計概的時候有談到的Presentation layerSession layer,因為在Internet裡這兩個layer並不明    

               

        ISO/OSITCP/IP的對照

        ISO International Standardization Organization

        ISO的網路modelOSI model, Open System Interconnect reference model

        internet之前,各公司都是自己一套的網路protocol,屬於比較封閉的資源

        internetopen,美國國防部的一個計劃,最後ISO照當時網路狀況定了七個層次

       

傳一個messagesourcedestination,applicatino打一個網址 ,network 以上都是軟體加頭切割後往下層傳,trasnsport開始加的資訊是segmentdatagram,最後link加的頭是frame,linkinternet的卡,再連著線傳到switch,physical開始往上層,link時可以看到layer2frame,若兩台電腦在同個區域就不會傳出去到router,直接在layer2回到另一台電腦否則再往外傳到更外圈的router,如果還在更外圍就再往外面的router,傳到最後的server再把資料一層一層扒開來得到網頁資訊,再包裝後將response一層一層的傳回去到source

 

每個layer傳遞資訊的基本單位是pdu, protocol data unit,

applicationpdumessage

transportsegment

networkdatagram

link layerframe

 

綱路的安全

網路攻擊有很多種,可以攻擊網路也可以攻擊電腦,軟體方面發展者和管理者都有可能出問題使用者沒有概念的話也是一個問題,發展者就是web程式沒寫好,管理者佔非常大不管發展多好管理者亂七八糟也是沒用

web2.0後發展者問題會更多,因為web API可以更多元使用

 

Denial of service attacks

        將服務資源佔用,讓合法的使用者無法取得服務

Packet sniffing

        將傳送的packet資料在半路截取走

                解決方法只有加密跟解密(Encrypt/Decrypt)

IP spoofing

        偽裝成要傳送的目的

                可用端點認證來解決(End-point authentication)

record-and-playback

        只是紀錄下來偷看

       

Application layer

網路的程式至少都兩個,一個client一個server兩端,再透過網路溝通,  中間的router很少有應用程式,通常只負責接收和傳遞資料,屬於比較封閉式的使用者使用是看到application,作業系統則只看到process,只管process用了什麼資源,何時交還權限

       

        application結構分三種

                Client-Server

server是一個always onhost,有個permanentIP address,server不見得一台,一個網址後面可能有一群server

                        client是向server取得服務的電腦,需要的時候再上線,不一定需要固定的IP address

                P2P(Peer-to-Peer)

                        沒有一個人是server,

                Hybrid of Client-server and P2P

skype前身是kazza,skypeMSN相同,一開始都需要先連到centralized server,再建立clientclientconnection,這時候才開始P2P

        以作業系統的角度看是兩個process,clientserverprocess可以擺在同一台

        processprocess溝通是inter-process,由作業系統所提供

       

        Sockets是怎樣寫網路程式應用的API,transport layer提供,負責sendreceive,

        socket只管網路上面的接送,真正讀取寫入還是要靠IO

 

        IP address 代表一個機器的一個介面,一台電腦可以不只一個IP

        但一台電腦不只一個process,所以還需要port協助

        HTTP server:80

        Mail server:25

        bbs port:23

        FTP:21

       

public-domain protocols

        ex.HTTP,SMTP

        RFC來定義

        RFC

                Request For Common

        允許interoperability,一起運作

Proprietary protocols

        沒公開的

        ex.Skype

 

socket API時可以選TCPUDP

        TCP

                connection-oriented

                        建立連線

                reliable transport

                        先送先到後送後到,漏了補足

                flow control

                        一邊快一邊慢時將快的速度降下來

                congestion control

                        由端點行為發現塞車時做收送的自我控制

                does not provide

                        不保證即時送達、每秒傳輸大小

        UDP

                什麼都不保證,TCP給的UDP都沒給

 

不同的應用特點也不同,下層需要的transport service也不同

有些資料可以loss有些不行,需求頻寬也不同,

 

Transport service requirements of common apps

Application

Data loss

Bandwidth

Time Sensitive

file transfer

no loss    

elastic

no

e-mail     

no loss    

elastic

no

Web documents

no loss    

elastic

no

real-time audio/video

loss-tolerant

audio: 5kbps-1Mbps

video:10kbps-5Mbps

yes, 100’s msec

stored audio/video 

loss-tolerant

same as above

yes, few secs

interactive games  

loss-tolerant

few kbps up    

yes, 100’s msec

instant messaging

no loss

elastic

yes and no

 

Application

Application layer protocol

Underlying transport protocol

e-mail

SMTP [RFC 2821]

TCP

remote terminal access 

Telnet [RFC 854]

TCP

Web

HTTP [RFC 2616]

TCP

file transfer

FTP [RFC 959] 

TCP

streaming multimedia

proprietary (e.g. RealNetworks)

TCP or UDP

Internet telephony

proprietary (e.g., Vonage,Dialpad)

typically UDP

 

TCP

        OSPF        Open Shortest Path First

        BGP         Border Gateway Protocol

        SMTP       Simple Mail Transfer Protocol

        NNTP       Network News Transport Protocol

        HTTP        HyperText Transfer Protocol

        Talnet

        FTP          File Transfer Protocol

UDP

        DNS         Domain Name System

        BOOTP    Bootstrap Protocol

        RPC          Remote Procedure Call

        SNMP      Simple Network Management Protocol

 

HTTP本身是stateless,每個message建立一個TCP連接,request過去response回來就結束了,但現在的web功能需要的狀態是連續的,這就需要cookie,還有一些其他技術輔佐

 

HTTP1.0HTTP1.1差別

HTTP1.0:RFC 1945

HTTP1.1:RFC 2068

1.0   Nonpersistent

        一個物件開一個TCP connection,另一個物件再開一個 TCP connection

       

                         Client     --要求建立 TCP connection--- Server

                                        <-----同意建立 connection---

    URL傳到Server ----HTTP request message--->

                                        <---HTTP response message--- 網頁、Header等資訊

                                        <---close connectino-------- Server

                         Client --重新建立 TCP connection-->

                       

1.1加入 persistent connection,persistent pipelining,cookie,session,proxy

        persistent connection

                不必為每個物件的傳送建立一個新的連接然後中斷,等下一個物件再建立新的連接

                1.1後一個連接中可以傳輸多個對象,

                像一個網頁中很多圖片就能經由原來的connection傳送

 

   Client      ---建立 TCP connection-->            Server

       RTT ←{                                                            

                        <-----connection OK------

                        -----------URL---------->

           RTT ←{                                                         

                        <---------HTML----------- file transmit time

                     ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

                        Total: 2RTT + transmit time

                        RTT,round-trip time        一個封包從client server在回到client的時間

        Persistent HTTP 還有pipelining跟沒有pipelining兩種

        Persistent without pipelining

                傳完第一個物件再傳第二個,以此類推,來回要一個RTT

        Persistent with pipelining

                拿到HTTP資訊,知道有幾個物件後就一次送幾個request過去,1.1後就是用這個

 

HTTP request message

        GET /somedir/page.html HTTP/1.1        request line

        Host: www.someschool.edu                    →主機的host名稱              

        User-agent: Mozilla/4.0                          client端的瀏覽器              |→header line

        Connection: close                                                                                   

        Accept-language:fr                                                                                

 

Method type

        HTTP 1.0只有GET, POST, HEAD

        HTTP 1.1除了GET, POST, HEAD

        還有PUTDELETE,就可以在網頁透過瀏覽器遠端管理網站的內容,當然之前會先有認證的功能

       

HTTP response message

        HTTP/1.1 200 OK                                                             status line

        Connection close                                            

        Date: Thu, 06 Aug 1998 12:00:15 GMT         

        Server: Apache/1.3.0 (Unix)                               header line

        Last-Modified: Mon, 22 Jun 1998 ... 

        Content-Length: 6821                                    

        Content-Type: text/html                                

                ↓網頁data

 

response 常見狀態訊息

        200 OK

        request succeeded, requested object later in this message

        301 Moved Permanently

        requested object moved, new location specified later in this message (Location:)

        400 Bad Request

        request message not understood by server

        404 Not Found

        requested document not found on this server

        505 HTTP Version Not Supported

       

cookie,SSL,javaScript都是Netscape公司所建

SSL,Secure Sockets Layer,一種安全保密的通訊協議

cookie

        Server端存在瀏覽器端的小資料,很多web狀態需要連續,可以把cookiesession變數

        存在cookie,讓上層應用可以在client端平台運用

proxy

        為節省頻寬,過去大家有共同應用的就在proxy做存取就可以了,也可以用來跳過IP封鎖

網概9/16筆記

ntework host
 網路的核心
  網路設備 browser,  一般人比較天天去碰到的
network edge
 網路的邊緣(電腦 )
bps, bit per second
網路談到的b
 bit
電腦裡的b
 byte
 
Internet
 best effort(unreliable)
 
protocol 協定
 講同樣的語言
 是一種規範,像
  format 格式
  order 要回應什麼
  接到後要做什麼事
 protocol data units
 怎樣接跟送messageEdge等

end systems run 各種程式
 
client/server
 server不在網路的核心,在另一端網路的edge上
 server死大家都一起死,所有東西都要經過server
peer - peer
 skype ,bitTorrenth
 
Network edge
 reliable data service
  TCP
   in-order byte
    先傳先到後送後到 flow control
    congestion control
     塞車時節制不能再上去,消化控制,慢下來,顧全大局不捐害到其他人傳輸
   ex. HTTP(Web), FTP(file transfer),Telnet(remote login),SMTP(email)
  經過handshaking後連線
   維護中間可靠link的機制
    中間有資料lost掉,下層再幫忙補出來
 unreliable data service
  UDP
   封包到處走,不建立連線
   可能先送後到或後傳先到
    ex. 多媒體,DNS,Internet telephony
     強調連線,重送反而delay太大
      先後順序的導正由應用(播放器)來做
 
 HFC
  hybrid fiber coax
   第四台提供
   後端外面光纖接進家裡是銅軸電纜
  cable modems 第四台的連結
   家裡第四台連結經過Fiber Node(第四台提供的),有個小機房大機房,
   也可以有光纖的連結,以美國為主,一條線上一些頻寬留著看電視,另外
   一些頻帶拿來當作上網,一個第四台主機連到500到5000個人家
   經過Set-Top Box(機上盒)

 LAN local area networks,也就是一般所說的區域網路

 edge router
  最邊緣的router,網路邊緣不連裝置不連主機的router,讓這些裝置連上去
  網路的router
  
 無線網路的基地台 base station 有時叫 AP access point
 WiMAX 更大頻寬更快速的
 wireless LANs 802.11b/g(WiFi):11 or 54 Mbps
 PHS 快速行動時就沒有辦法接收

 一般用的網路線 TP(Twisted Pair) 現在通常是Category 5 (100M/1G bps)

 衛星delay為 270 msec

Network Core
 核心的部份就是一大堆的router起來
 data在router間走動有兩大方法
  像傳統電話一樣建立一條線 circuit switching
   平分資源的方法
    FDM frequency devision multiplexing
     一段線分幾個頻帶
    TDM time devision Multiplexing
     每段時間分開給不同人
    壞處:不用的時候頻率、時間會浪費掉
  Packet Switching
   將資料切成小的packet,每個packet使用full link bandwidth
    壞處:大家都很忙的時候競爭激烈,分配的複雜度比較高

Ethernet乙太網路發展歷史

Ethernet,中文翻譯為乙太網路,可算是所有區域網路中發展最成功,普遍性最高的技術

不管是個人電腦,終端機還是大型主機都是藉由此技術連結成區域網路,再從這些區域網路連接網際網路

 

Ethernet發展至今差不多30,1973年時由Xerox(全錄)公司的PARC,Palo Alto Research Center(帕羅奧托研究中心)研發設計推出的第一個區域網路系統,隨即由計劃負責人Metcalfe博士命名為Ethernet,命名的含義是EtherNetwork兩字的組合(在早期Ether是假想為用來傳遞電磁波的物質,當然後來證實是不存在的),剛推出之時的Ethernet頻寬僅僅只有2.94Mbps,而且只於公司內部使用,並沒有把他商業化

 

一直到1982,DEC,IntelXerox組成的DIX聯盟發表了Ethernet Version 2 規格(簡稱EV2),將頻寬提升為10Mbps,正式將Ethernet投入市場,推出的產品為「10 Base 5 Ethernet,之後IEEE也根據EV2的內容略加修改後在1983年正式通過了802.3 CSMA/CD 規格

 

10 Base 5 Ethernet採用RG11 A/U 同軸電纜為傳輸介質,電纜的兩端必須接上50歐姆終端電阻,由終端電阻到另一個終端電阻之間的範圍稱為一個Segment(區段),每段Segment可達500公尺,最多可連接100部電腦,由於這是第一個標準化的Ethernet,也被稱為「標準乙太網路」

 

由於10 Base 5 佈線不易且成本過高,於是3Com公司推出了改良型產品,10 Base 2 Ethernet,改用較細的RG58 A/U同軸電纜當作傳輸介質,電纜的兩端一樣要接上50歐姆終端電阻,兩終端電阻之間的範圍稱為Segment,但是最大長度縮減為185公尺,每個segment最多可連接30部電腦,雖然區段縮小,連接的電腦數目也減少,但是因為施工容易,材料價格低廉等優點逐步淘汱掉第一代的10 Base 5 Ethernet

 

不管是10 Base 5還是10 Base 2都有以下兩個缺點

1.      網路的任何一處斷線,都會導致整個網路停擺,而且追查斷線點較為困難

2.      若有電腦要移動位置,佈線路徑可能需要大幅修正

 

因為管理維護上的不便促使了新一代乙太網路10 Base T Ethernet的誕生

10 Base T Ethernet採用UTP(Unshielded Twisted Pair,無遮蔽式雙絞線)為傳輸介質,所有的電腦都透過Hub互相連接,電腦到Hub的最大長度為100公尺

 

10 Base T Ethernet具有以下優點

1.      每部電腦都獨立連接到Hub,如果電腦或線路發生問題,只會影響本身這一段的線路,不會影響其他電腦的運作

2.      Hub的燈號狀況反應即可判斷哪段線路故障,維護比較容易

3.      移動電腦時不必改變整體佈線路徑,只需更動局部佈線路徑即可

 

提高網路傳輸效益最直接的方法就是增加頻寬,Ethernet服務10年之後,1995IEEE發表了Fast Ethernet標準-802.3u,其中定義了3100 Mbps Ethernet規格,摘要如下(後來在1997年的802.3y中又加入了一個新規格)

 

100 Base TX

100 Base T4

100 Base FX

100 Base T2

介質

Category 5以上的UTP

Category 3以上的UTP

光纖

Category 3以上的UTP

所需傳輸線數目

2

4

2

2

相關標準

802.3u

802.3u

802.3u

802.3y

備註

和10 Base T 系統相容

 

 

 

名稱中T代表Twisted Pair ,F代表Optical Fiber , 4代表4對線, 2代表2對線

 

100 Mbps全面取代10 Mbps之後,另一波頻寬增加已經在悄悄地醞釀,因為100 Mbps 只滿足了眼前的需求,並沒有替未來的發展預留空間,如果要在區域網路中提供多媒體服務像線上會議,影像電腦,隨選視訊等,100 Mbps還是稍嫌捉襟見肘了點

 

因此IEEE1998年通過1000 Mbps Ethernet 標準-802.3z,因為是1000 Mbps,這個 Ethernet也通稱為Gigabit Ethernet,在緊接著在2002年推出10 Gbps也就是10000 Mbps的標準-802.3ae,不過由於Giga級的乙太網路設備並不常見,價格也顯得比較昂貴,目前主要用途還是充當網路的骨幹線路

下面整理了當前Ethernet規格列表

代碼

IEEE規格標準

標準通過年份

頻寬

使用線材

10 Base 5

802.3

1983

10 Mbps

粗同軸電纜

10 Base 2

802.3a

1988

10 Mbps

細同軸電纜

10 Base T

802.3i

1990

10 Mbps

Category 3等級以上的UTP

10 Base F

802.3j

1992

10 Mbps

光纖

100 Base TX

802.3u

1995

100 Mbps

Category 5等級以上的UTP

100 Base T4

802.3u

1995

100 Mbps

Category 5等級以上的UTP

100 Base FX

802.3u

1995

100 Mbps

光纖

100 Base T2

802.3y

1997

100 Mbps

Category 3等級以上的UTP

1000 Base SX

802.3z

1998

1000 Mbps

光纖

1000 Base LX

802.3z

1998

1000 Mbps

光纖

1000 Base CX

802.3z

1998

1000 Mbps

特殊同軸電纜

1000 Base T

802.3ab

1999

1000 Mbps

Category 5級以上的UTP

10 G Base-SR

802.3ae

2002

10Gbps

光纖

10 G Base-LX4

10 G Base-LR

10 G Base-LW

10 G Base-SW

10 G Base-ER

10 G Base-EW

 

Ethernet的資料連結

位於Ethernet上的所有電腦都共用同一個傳輸介質也就是網路線,當然會面臨使用上誰先誰後的問題,要解決這個問題當然必須訂定一套傳輸介質使用管理辦法,以網路術語來說就是『MAC Method,(Media Access Control Method),Link Layer的下半就是用來處理MAC,Ethernet使用的MAC Method就是CSMA/CD,全名Carrier Sense Multiple Access with Collision Detection.

無線網路比較


現在無線網路需求量越來越大,使用上也越來越方便,很多人都在傳言WiMAX將是台灣下一代無線網路的主流,最近也有不少表示內建WiMAX的筆記型電腦,關於移動式WiMAX 802.16e行動裝置、基地台等相關產品也是越來越多WiMAX擁有高速率、長距離、高移動性的特點,可以提供優於3G及DSL的傳輸速率。綜觀目前發展的各個無線網路規範,大多數人使用的仍是屬於室內的ADSL+無線區域網路,以及現在多家電信業者極力在推廣的3G、3.5G手機行動通訊上網服務。
根據資策會研究資料顯示,以在2007年投入WiMAX業者家數為單位,使用3.5GHz與2.5GHz業者共佔約86.9% .而就覆蓋用戶數而言,顯示在WiMAX幾個關鍵頻譜(2.3GHz、2.5GHz與3.5GHz)當中,目前雖然無任何一個頻譜可以通用全球,但是2.5GHz及3.5GHz已成為主要使用頻譜,未來 WiMAX產品設計亦將以雙模方式滿足跨國漫遊需求。
因此,WiMAX不僅可以透過自己特有的網路與基地台連線,和ADSL或3G手機一樣作為連線上網的用途,且在電信業者進行完整
的網路佈建後,就能發揮其優勢 。

(目前資策會的資料,目前國內有六家電信業者包含大眾電信、全球一動、威邁思電信、大同電信、遠傳電信、威達有線電視,
前三家為北區,後三家為南區,這些業者已於2007年7月份獲得 WiMAX分區執照,將陸續提供Mobile WiMAX服務)。


WiMAX、Wi-Fi、2G、2.5G與3G的比較

項目類別

無線網路

行動網路

WiMAX

Wi-Fi

3G

2G/2.5G

起始年

802.16d : 2004
802.16e : 2005

802.11a/b : 1999

802.11g : 2003

802.11n : 2005

2003

2G : 1992

3G : 2000
採用國際標準

IEEE802.16d(行動式)
IEEE
802.16e(固定式)

IEEE802.11a : 54Mbps
IEEE802.11b : 11Mbps
IEEE802.11g : 54Mbps
IEEE802.11n : 600Mbps

CDMA2000
TD-SCDMA
WCDMA

CDMA
GPRS
GSM
TDMA

使用頻譜

免執照 : 5.8GHz
需執照 : 2.3GHz、2.5GHz、3.5GHz

802.11a : 5GHz
802.11b/g : 2.4GHz
80-2.11n : 2.4GHz/5GHz
(以上皆免執照)

IMT-2000 

GSM900
DCS1800
PCS1900 

最高傳輸率

 75Mbps

54Mbps(11n為草案,目前採行的draft2.0已進入最後階段,通過後可達600Mbps) 

348Kbps~2Mbps 

9.6Kbps~172Kbps 

可涵蓋範圍

空曠地區 : 約30公里
都會區 : 約2~7公里

室外範圍 : 250公尺
室內範圍 : 70公尺
(此數值以11n來計,此為圓周直徑蓋範圍)

 

平均傳輸半徑 : 0.5~5公里 

平均傳輸半徑 : 0.5~5公里 

特點

1.高速傳輸率 : 75Mbps
2.涵蓋範圍大 : 空曠區約30公  里、都會區2~7公里
3.高移動性 : 時速可超過100公里

1.高傳輸率 : 11n通過後可達600Mbps
2.範圍較短 : 室外250公尺
3.低移動性 : 適合定點接收

1.較2G、2.5G傳輸率約提昇10位左右
2.可接收影像電話、即時影音播放、行動電視等服務 

1.核心為數位語音傳輸技術
2.2.5G傳輸率較2G提高

以上比較皆為理想的數值,實際的傳輸率與涵蓋範圍,會因使用環境或多種不同因素而有所影隌。
WiMAX : Worldwide Interoperability for Microwave Access (全球互動微波存取)
WiFI : Wireless Fidelity (無線區域網路)
3G : 3rd Generation (第3代行動通訊技術)
2G/2.5G : 2rd/2.5rd Generation (第2、2.5代行動通訊技術)

另外有些常見的無線網路名詞

英文縮寫

英文全名

中文直譯名稱

採用的規格

WPAN

Wireless Personal Area Network

無線個人區域網路

藍牙、WUSB/W1394UWBZigbee

WLAN

Wireless Local Area Network

無線區域網路

IEEE802.11a/11b/11g/11n

WMAN

Wireless Metropolitan Area Network

無線都會區域網路

WiMAX

WWAN

Wireless Wide Area Network

無線廣域網路

CDMA2000EDGEGSMsGPRSHSDPAHSUPAPHSWCDMA

以上目前皆通稱為Wi-Fi的無線區域網路

表格參考自 Digitrend 第36期

Silverlight使用心得

Silverlight是微軟針對新一代Web所推出的技術,具備了優越的向量動畫、繪圖及影音播放能力,目的是為了提升使用者經驗以達到更好的視覺化效果與互動性。而且雖然Silverlight是微軟所創,但並不只限定IE運行,在其他平台瀏覽器像FireFox等都有支微。

 

輕量級的安裝元件,檔案容量輕巧,不到2MB大小的plug-in可以讓使用者輕鬆下載安裝

 

Silverlight本身renderXAML為基礎,除了能產生向量文字,更有2D繪圖與影音播放的能力,並可與使用者進行雙向互動

 

能輕易地應付影音檔在Internet上的播放,不管是WMVwma還是MP3格式的媒體,在Silverlight通通只需要一行XAML程式就可以搞定

 

Silverlight並不是自創一格的黑箱程式,使用者可以透過JavaScript存取Silverlight物件,並且可以與既有的HTMLDOMCSSAJAX技術進行整合互動,讓各種技術可以互相搭配運用

 

想要進行Silverlight的開放只需要安裝最基本的Silverlight Runtime Componet軟體即可,完全不需要複雜的IDE開發環境或IIS等,這是因為Silverlight的執行是在Client端的瀏覽器之中,和WebServer無關

安裝Silverlight可以到http://www.microsoft.com/silverlight/resources/install.aspx

安裝完全後就可以馬上執行任何Silverlight的應用程式,而開發Silverlight用最基本的文字編輯軟體像記事本NotePad這些就可以了,然後熟悉JSPPHP的開發人員也可以使用其他的IDE環境做開發

 

本次範例是採用TextBlock來宣告文字,並搭配Clip裁切的技巧

ClipTextBlock物件本身提供的一個屬性,專門用來進行物件的裁切,而想切成什麼形狀必需在Clip屬性區段中加入Geometry幾何繪圖的宣告,範例中是做Ellipse圓形切割,也可以用其他像星形三角形等其他幾何圖形做裁切。

 

另外如果只是用最基本的TextBlock來宣告文字,如果文字太長並不會自動斷行,就算在編輯時自己手工斷行也沒用,似乎對XAML語法而言這是無效的,仍然會以一行來顯示所有文字,其餘過長的部份則會被截斷,無法完整顯示所有文字。

 

解決的辦法是必需在TextBlock屬性內加入TextWrapping屬性將其設定為Wrap

<TextBlock Width = “400” TextWrapping = “Wrap”>很長的文字</TextBlock>

這樣一來文字超過無法顯示的部份就會自動換行囉!

成品網址: http://www.csie.fju.edu.tw/~ie955156/SilverlightTest.html

頁面