Nghiên cứu so sánh các phương pháp ước lượng băng thông đương truyền trong hệ thống http streaming

L Công nghệ truyền video trên giao thức HTTP là công nghệ đ sẽ đ ợc ứng dụng rộng rãi trong các ứng dụng xem video trực tuyến trên các thiết bị đ ệ.. Tuy nhiên, một trong nh ng yêu cầu

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

LUẬN VĂN THẠC SĨ KỸ THUẬT

KỸ THUẬT VIỄN THÔNG

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

Chuyên ngành: Kỹ thuật viễn thông

LUẬN VĂN THẠC SĨ KỸ THUẬT

KỸ THUẬT VIỄN THÔNG

NGƯỜI HƯỚNG DẪN KHOA HỌC:

PGS.TS PHẠM NGỌC N M

Hà Nội – 2015

ỤC ỤC

M C L C 1

LỜI C M O N 4

NH M C TỪ VI T TẮT 5

NH M C C C NG I U 7

NH M C C C H NH V , Ồ TH 8

PHẦN MỞ ẦU 10

CHƯ NG I: KH I QU T HỆ THỐNG HTTP STR MING 14

1.1 Tổng quan về HTTP 14

1.1.1 Khái niệm 14

1.1.2 Mô hình HTTP 15

1.2 Tổng quan về Streaming 17

1.2 ệ Streaming 17

1.2.2 Tính phổ biến của Streaming 18

1.2.3 Bă g t ô g và lưu trữ tr g t u t Streaming 19

1.2.4 Các vấ đề về giao thức 20

1.2.5 Các ứng dụ g đ ển hình và khái niệm tiếp thị mới 22

Kỹ ậ HTTP S 22

1.3 u đ ể ủ v ệ ụ g g t ứ 22

1.3.2 HTTP Streaming 24

1.4 Kết luậ I 29

CHƯ NG II: TỔNG QU N V ĂNG TH NG V ƯỚC LƯ NG ĂNG TH NG 30

2 C ệ 30

2.1.1 Bă g t ô g 30

2 ô g lư g 30

2.1.3 Bitrate 31

5 Bă g gốc 34

2.1.6 Bộ đệm 35

2.1.7 Mạng máy tính và mô hình phân tầng 35

2.2 Thích ứng Streaming và DASH 42

2.3 Thi hành thích ứ HTTP S đ đ ờng 47

2.4 Các bộ mã hóa và gi i mã Video (Video CODECs) 48

2.4.1 Các khung hình video 48

2.4.2 Giải mã và dấu thời gian trình diễn 49

2.4.3 H.263 49

u -4 AVC 50

5 Định dạ g u 51

2.5 Audio CODECs 52

2.5.1 MP3 52

2.5.2 K thu t mã hóa âm thanh tiên tiến (Advanced Audio Coding-AAC) 53

2.5.3 Vorbis 54

2 6 ịnh d ng bộ chứa (Container format) 54

2.7 Các mức chấ l ợng video 55

2.8 Dịch vụ truyền hình theo yêu cầu và truyền hình trực tiếp 56

2.9 Kết luậ II 57

CHƯ NG III: C C PHƯ NG PH P ƯỚC LƯ NG ĂNG TH NG ƯỜNG TRUY N TRONG HỆ THỐNG HTTP STR MING 58

P ớ l ợ ự đ ố 58

3.1.1 Các yêu cầu củ p ươ g p p 58

3.1.2 Thu t t ướ lư g ă g t ô g tr p đ ạ uố g 59

2 P ớ l ợ ự l ị 60

3.2.1 Thu t t ướ lư g tr là ị ă g t ô g 60

ô g v ệ l u 62

P ớ l ợ ế ợ ự đ ố l ị

thông 64

y g à t tổ g u t 64

u t t ướ lư g ết p tr p đ ạ uố g và là ị ă g thông 65

3.4 Kết luậ III 68

CHƯ NG IV: MÔ PHỎNG VÀ SO SÁNH C C PHƯ NG PH P ƯỚC LƯ NG ĂNG TH NG ƯỜNG TRUY N TRONG HỆ THỐNG HTTP STR MING 69

C đ ệ ố 69

4.1.1 S u ị nội dung 70

4.1.2 Máy chủ HTTP 72

4.1.3 Client 74

4.1.4 Bộ mô phỏ g đường truyền mạng (network emulator) 79

4.2 Mô phỏ ớ l ợ ự đ ố 81

ô trường mô phỏng 81

4.2.2 Kết quả th c nghiệm 82

4.3 Mô phỏ ớ l ợ ự l ị 84

4.3.1 Mô phỏ g p ươ g p p 84

ết uả t g ệ 86

4.4 Mô phỏ ớ l ợ ế ợ ự đ ố l ị 86

4.4.1 Mô phỏ g p ươ g p p 86

ết lu 92

5 S s ợ đ ểm củ y 92

4.5 Kết luậ IV 95

K T LUẬN V HƯỚNG PH T TRI N T I 96

NH M C T I LIỆU TH M KH O 100

N ỤC T V T T T

3GPP Third Generation Partnership Project

AAC Advanced Audio Coding

ADSL Asymmetric Digital Subscriber Line

ARP Address Resolution Protocol

CBR Constant Bitrate

CDN Content Delivery Network

CODEC Compessor-DECompessor

CSS Cascading Style Sheets

DASH Dynamic Adaptive Streaming Over HTTP

DNS Domain Name System

FEC Forward Error Correction

FTP File Tranfer Protocol

GIF Graphics Interchange Format

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IGRP Interior Gateway Routing Protocol

IP Internet Protocol

JPG Joint Photographic Group

LAN Local Area Network

MAN Metropolitan Area Network

MAC Media Access Control

MDP Media Presentation Description

MPEG Moving Picture Experts Group

MP3 MPEG-1 audio Player 3

MP4 MPEG-1 audio Player 4

NAT Network Address Translation NAT

NIC Network Interface Card

NNTP Network News Transfer Protocol

OSI Open Systems Interconnection

P2P Peer-to-Peer

PC Personal Computer

PSNR Peak Signal-to-Noise Ratio

RAP Random Access Point

RIP Routing Information Protocol

RTCP Real-time Transport Control Protocol

RTP Real-time Transport Protocol

RTSP Real-time Streaming Protocol

RTT Round-Trip Time

SMTP Simple Mail Transfer Protocol

SSL Secure Socket Layer

TCP Transmission Control Protocol

TLS Transport Layer Security

UDP User Datagram Protocol

URL Uniform Resource Locator

URI Uniform Resource Identifier

URN Uniform Resource Name

VBR Variable Bitrate adaptation

VLC Video Lan Player

WAN Wide Area Network

N ỤC C C NG U

Bả g Bả g t ố g lưu lư g ụ g t r t tr t à ầu ủ gườ t u

g B ỗ t g ) 10

Bả g u ơ ản giữa ba cấu hình CBP, BP và MP củ u H.264 51

Bả g và u ỗ tr trên các dạng container 55

Bả g u t t ướ lư g ă g t ô g tr p đ ạ uố g 59

Bả g Đ ạ ã đư c s dụng cho thu t t ướ lư g ă g t ô g tr p đ ạ uố g 60

Bả g Đ ạ ã đư c s dụng cho thu t t ướ lư g tr là ị ă g t ô g 62

Bả g Đ ạ ã ơ ế đ ều khiển bằng p ươ g p p ướ lư g ết p tr p đ ạ uố g và là ị ă g t ô g 67

Bả g ụ nội dung t p t N L đư c tạo bởi Mp4box 71

Bả g Đ ạ ươ g tr t c hiện chuyển trạ g t ươ g tr đư c chạy 76

Bả g Đ ạ ươ g tr ủa play state 76

Bả g Đ ạ ươ g tr ủa buffering state 77

Bả g 5 ụ đ ạn mã cấu hình cho DummyNet 80

Bả g ụ đ ạn mã cho DummyNet 80

DANH ỤC C C N V , ĐỒ T

ô đơ g ả 15

ô p ứ tạp 16

ô p ứ tạp vớ ộ ớ 16

Quy trình Streaming Video 18

5 ả p p tr g ủ t y t ụ g p ầ ề L 20

tiến hóa c a sổ tắc nghẽn của TCP (Tahoe và Reno) 23

ờ g m trễ tr g v tr g à g ơ r 24

Luồng lưu trữ video trên HTTP / TCP 25

t ộ đệ y v tr g 27

ể tr ủ đườ g ạ g 32

ạ u đ ể g 33

ạ t ờ g g g g g t u đ ể g 34

Đị ủ y t ụ g ệ đ ều à w 37

5 Bả g đị tuyế ụ ộ ủ ệ đ ều à w w 39

ể tr đườ g đ đư ụ g tr g w w 39

tầ g ủ ô 40

ến trúc truyền HTTP 42

ấp của s phân chia nội dung và mứ độ tín hiệu siêu dữ liệu 43

ạt độ g đ đường song hành 47

phân bố các khung hình trong một luồng video stream 49

ấu ơ ản, chính và mở rộng của H.264 51

ô x đị lưu lư g g đ g ạng 65

ối quan hệ giữa giữ p và δ 67

ến trúc chung của hệ thống 69

ô khố u ị nội dung 70

Đặc tính trả về t ô g đ ệp phản hồi của máy chủ HTTP 74

ô ạt động của ứng dụng 74

5 ơ đồ chuyển trạng thái của khối player 75

Nội dung các thông số đư lưu trữ 78

ơ ế hoạt động của DummyNet 79

t ố ơ ản, Queue và pipe của DummyNet 80

ô ệ thống khảo sát 81

ô p p g ả l p, hạn chế ă g t ô g ạng 82

nh 4.11 Giao diện phần mềm eclipse SDK 83

ện c a sổ console khi hoạt động tốt 83

ện c a sổ console khi kết nối bị ngắt 83

Đồ thị kết quả đ đư t ơ ế ướ lư g ă g t ô g tr p đ ạ uố g 84

5 ụ ểu đồ đườ g đơ 84

B ểu đồ t tươ g ứng vớ đườ g đơ 86

Đồ thị kết quả đ đư t ơ ế ướ lư g tr là ị ă g thông 86

ột ví dụ MPD vớ t ă g ở rộng 87

o sánh giả p p đề xuất ết p pr p và g ải pháp theo tỷ lệ (proportional) 88

à v t ứng củ y đế t y đổ ă g t ô g ẵn trong một trường h p kết nối 90

à v t ứng củ y đế t y đổ ă g t ô g ẵn trong trường h p kết nối 91

Đồ thị kết quả đ đư t ơ ế ướ lư g ết p tr p

đ ạ uố g và là ị ă g t ô g 92

u g ữ p ươ g p p ướ lư g ă g t ô g 94

5 ạt độ g đ đường song hành 97

5 ô ối trên client 98

P ẦN Ở ĐẦU

1 L

Công nghệ truyền video trên giao thức HTTP là công nghệ đ sẽ

đ ợc ứng dụng rộng rãi trong các ứng dụng xem video trực tuyến trên các thiết bị

đ ệ Tuy nhiên, một trong nh ng yêu cầu trong các ứng dụ y l đ m b o chấ l ợng dịch vụ QoS tốt nhất có thể ời dùng b ng việ đ ều ch nh các thông số của video kịp thời theo sự biế đổi củ đ ờng truyền Vì vậy, bài ớ l ợ đ ờng truyền là bài toán quan trọ đ đ ợc nghiên cứu nhiều trên thế giới

đ ợ ổi lên bở yề thông công nghiệp Họ đề ựa trên HTTP và dựa vào nội dung giao thức mà chấ l ợng củ y đổi chứ ủa các

sẵ l i quyết b ng Färber et al [26] dự đ

ở Feng [43] làm việc dựa trên kh ở rộng mã hóa video Lợi ích của việc s dụng các giao thức HTTP trong nh ng gi i pháp ớ l ợ thông streaming là kh để ợt qua các bộ định tuyế N T ờng l a liền

m ch Gầ đ y GPP ờng nỗ lực của họ liên

đến HTTP dựa trên ớ l ợ thông s ầu tiên 3GPP ự trên đ đ ểm kỹ thuật về thích ứng streaming, cung cấp kh để lấy đ n

từ các máy chủ T y đ y l ột cấu l ể

ị cấu hình tập tin cho phép kết hợp một URL với mộ ú n phân khúc truy xuấ đồng thời

3

ề tài thực hiện nh m dựa trên nh ng mục tiêu chính sau:

- Xây dựng một hệ thống ho động dựa trên nguyên lý ho động của kỹ thuậ ớ l ợ đ ờ yề ệ ố HTTP S S dụng hệ thống trên làm mô hình chung trong việc nghiên cứ , đ yếu tố ràng buộc, ớng tới chấ l ợng của dịch vụ

- ề xuấ đ ột số thuậ đ ợc s dụng trong kỹ thuậ ớ

l ợ đ ờ yề ệ ố HTTP S C ế ớ

l ợ y đ ợc s dụng ở y , đ đ ợc thuật toán ho t động phù hợ , é ấp chấ l ợng dịch vụ tố , ố việc s dụ ời dùng

- ệ thống trên các kịch b n m ng khác nhau với các tố độ bit,

độ trễ gói, t lệ mất gói, chấ l ợng hình nh, thời gian từ đ n hình … Q

đ , ực hiệ đ ểm và kh ủ ế ớ l ợ

đ ờ yề ệ ố HTTP S để nâng cao hiệu suất trong

đ ều kiện khác nhau

Các giao tiếp truyền nhận s dụ đề tài nghiên cứ đều dự trên giao thức truyề s n (HTTP) và s dụng giao thức truyền nhận tin cậy (TCP)

đ , ức giao tiế y đ đ ợc hỗ trợ sẵ ức truyền luồng tin cậy ế tránh tắc nghẽn

Phần mở ầu: Trình bày về các vấ đề đ t ra, lý do và mục tiêu nghiên

cứu củ đề , đồng thờ õ ề ph m vi nghiên cứ đ ợc thực hiện trong nội dung của luậ

C : K hệ thống HTTP Streaming, y ề ệ

HTTP đ y ề ệ , ổ ế , ấ đề ề thông, l ấ đề ề ứ ỹ ậ S ồ

Tim Berners-L , ộ ọ y ờ ự

“W l W W ” l ờ đầ đ ợ ậ phát minh

ra HTTP ớ đ ấ s HTML (HyperText Markup Langu ), ệ liên quan đế y ủ web yệ w ự [8]

HTTP cho phép mộ ậ ứ lệ ( s s) đề ở-đ ( - ) để ụ

đ ủ ộ y ầ HTTP đ ợ y ự y ắ ế đ ợ

ấ ở đị y ố ấ (U f R s I f - URI), đị ị y ố ấ (U f R s L - URL) hay

máy khách ớ ộ y ủ ố ) đế ệ ố I , ồ

ệ ố ỗ ợ ứ yề đ (S l M l T sf Protocol – SMTP), ứ yề ứ l (N w N ws T sf Protocol – NNTP), ứ yề ệ (F l T f P l – FTP), giao

ứ G (đ ợ ế ế để ế l l ệ )

W IS ( ệ ố ế theo mô hình khách – ủ s ụ NSI

Z 9 50) y, HTTP é y ậ s ệ đế nguyên sẵ ừ ứ ụ đ [8]

1.1.2 Mô hình HTTP

G ứ HTTP l ộ ứ y ầ đ ứ [8] K ộ

y ộ y ầ đế y ủ ồ ứ y ầ ( ồ G T, POST, H ,…), URI, ứ , è ớ đ ệ ể MIM

ế l ấ ộ ầ ủ đ ệ yể ế y ầ đ đị

l ề y ủ đị ở URI Ở đ y, w y độ ộ lớ

y ở URI, ấ đề ế ố để ậ đề), ấ

ệ đ ờ , ệ ố ề ( N System – DNS) , đề , ấ đề sắ ế ộ , ấ đề ự y

4 Quy trình Streaming Video

1.2.2 Tính phổ biến của Streaming

1.2.3 Băng thông và lưu trữ trong thu t Streaming

ậ ớ , ở đ y ậ l ấ ỏ để ọ ể s s ớ streaming

ố ờ ợ s ụ RTSP RTP

Mộ ứ đ ậy, ẳ T s ss C l P l (TCP), sẽ đ yể đú ỗ s K y ệ

G ứ U s ộ s s ừ y ủ đế ỗ

ờ ậ U s l ầ ế ế ố I , y khô lớ ề ờ ố ộ yề

ờ l L N é để đế multicast

Khi chuyển một tập tin qua giao thức TCP từ các máy chủ tới khách hàng,

tố độ truyền t i có thể y đổ đ ể ế đ ều khiển tắc nghẽ TCP c biệt, nó không ph i là không phổ biến cho tố độ truyền khác nhau một “ ” (ví dụ Hình 1.6) kết hợp vớ đ ều khiển tắc nghẽn TCP

6 S tiến hóa c a sổ tắc nghẽn của TCP (Tahoe và Reno)

H a, các gói d liệ ể đ ợ đ ể do truyền l i của ế TCP Do nh đ đ ểm của TCP, ờng trong nh

1990 video streaming sẽ không bao giờ làm việc tốt trên TCP Tuy nhiên theo thời gian, thiết kế các hệ thống video streaming biế đ ều khiển tắc nghẽ TCP chế chuyển giao d liệu đ ậy

Việc s dụng HTTP qua TCP é đ đ ờng

l a và NAT dễ ( ờ đ ợc cấ để ch n hầu hế l l ợng

U P é hầu hết l l ợng truy cập HTTP) Truyề HTTP

ừa sự cần thiế đ ều khiển truyền thông máy chủ, chẳng h ột máy chủ RTSP, gi m chi phí việc triển khai quy mô lớn qua Internet Do tất c

đ ểm trên, hầu hết các ứng dụng video streaming ngày nay, bao gồm c YouTube và Netflix s dụng HTTP streaming (trên TCP) là giao thức truyền

t n

1.3.2 HTTP Streaming

1.3.2.1 Tìm nạp video

Chúng tôi biết đ ợc, bộ đệm bên phía khách hàng có thể đ ợc s dụ để

gi m thiểu ởng của việ y đổi chậm trễ end-to- y đổ thông có sẵn [14] Trong ví dụ t i Hình 1.7, các máy chủ truyền video ở tố độ mà

đ n video sẽ đ ợ

7 ờ g ch m trễ trong video streaming à g ơ r

Tuy nhiên, cho các tuyế l video, các khách hàng có thể ph i cố gắng

để t i về video ở tố độ c ố độ tiêu thụ, đ ớ đ n khung

đ ợc s dụng l Video tìm n ớc này là tự nhiên đ ợ l

tr trong bộ đệm ứng dụng khách hàng Tìm n ớ đ y ra một cách tự nhiên với TCP streaming, kể từ ế tránh ùn tắc TCP sẽ cố gắng s dụng tất c các a máy chủ và máy khách ể đ đ ợc một số cái nhìn sâu sắc vào tìm n ớc, chúng ta hãy xem xét một ví dụ đ n sau

Gi s t lệ tiêu thụ l M s ng có kh ấp các video từ máy chủ tới khách hàng với một tố độ đổi là 1,5 Mbps Sau

đ , sẽ không ch các video với sự phát sóng chậm trễ rất nhỏ,

sẽ có thể l l ợng d liệ đệm b ng 500 Kbits hàng thứ hai Theo cách này, nế l ậ đ ợc d liệu với tố độ nhỏ M s ột kho ng thời gian ngắn, khách hàng sẽ có thể tiếp tục cung cấp liên tục việc phát l i do có l ợng dự tr trong bộ đệm của nó, [4] cho thấy r ng khi các thông l ợng TCP trung bình gần gấ đ ố độ bit truyền thông, kết qu truyền qua TCP thì n đ sự chậm trễ của bộ đệm là thấp tối thiểu

1.3.2.2 Bộ đệm ứng dụng máy khách và bộ đệm TCP

Hình 1.8 minh họa sự a khách hàng và máy chủ HTTP streaming Ở phía máy chủ, các phần của file video trắ đ đ ợc g i vào socket của máy chủ, trong khi phần tối là nh ng gì còn l đ ợc g đến sau "k đ

c s ," y đ ợ đ ớ đ ợc truyền vào m ng Internet

8 Luồng lưu trữ video trên HTTP / TCP

Trong Hình 1.8, vì bộ đệm g i TCP đ ợ đầy, các máy chủ trong giây lát

n từ việc g i thêm byte từ file video vào socket Về phía khách hàng, ứng dụng khách hàng ( l y ) đọc byte từ bộ đệm nhận TCP (thông quasocket khách hàng củ ) đ t các byte vào bộ đệm ứng dụng khách hàng T i cùng

một thời gian, các ứng dụ định kỳ lấy khung động từ các bộ đệm ứng dụng khách hàng, gi i nén các khung hình, và hiển thị chúng trên màn hình củ ờ L u ý r ng nếu bộ đệm ứng dụng khách hàng là lớ s với các tậ , s đ ộ quá trình di chuyể y l của máy chủ đến bộ đệm ứng dụng củ l đ cho một tập tin t i về Thông ờng qua hệ thống HTTP-khách hàng ch cần kéo đ đ , các máy chủ TCP sẽ cho phép!

Hãy xem xét nh ng gì sẽ x y ời dùng t m dừng video trong quá trình streaming Trong thời gian t m dừ , đ ợc gỡ bỏ từ bộ đệm ứng dụng khách hàng, m c dù tiếp tục nhập bit từ các bộ đệm máy chủ Nếu bộ đệm ứng dụng khách hàng là h u h n, nó có thể trở nên đầy, sẽ gây "áp lực trở

l i" tất c các đ ờng trở l i máy chủ Cụ thể, khi bộ đệm ứng dụng khách hàng đầy, byte có thể đ ợc gỡ bỏ khỏi bộ đệm nhận từ TCP khách hàng, vì vậy

n ở đầy Một khi khách hàng TCP nhậ đ ợc bộ đệ đầy, byte có thể đ ợc gỡ bỏ từ các TCP bộ đệm g i khách hàng, đ ở nên đầy Một khi bộ đệm TCP g i trở đầy, máy chủ không thể g i byte vào socket

n đ , ế ời dùng t m dừng video, máy chủ có thể bị buộc ph i ngừng truyề , ờng hợp này máy chủ sẽ bị ch đế ời s dụng tiếp tục l i các video

Trong thực tế, ngay c khi phát l ờ y ( l , ừng

l i), nếu bộ đệm ứng dụng khách hàng trở nên đầy, áp lực trở l i sẽ gây ra các bộ đệm TCP trở đầy, mà sẽ buộc các máy chủ gi m tố độ củ ể định

kết qu tố độ, l ng khi các ứng dụng khách hàng lo i bỏ f bit, nó t o ra f bit

cho ự phòng trong bộ đệm ứng dụng khách hàng, đ é y ủ

g i f N ậy, tố độ máy chủ g i có thể ức tiêu thụ

tố độ video khách hàng Vì vậy, một bộ đệm ứng dụng khách hàng đầy gián tiếp

đ t một giới h n về t lệ mà video có thể đ ợc g i từ máy chủ cho khách hàng khi streaming qua HTTP

1.3.2.3 Phân tích Video Streaming

Một số đ n sẽ cung cấp cái nhìn sâu sắ sự trì hoãn

s đầ đ sự c n kiệt bộ đệm ứng dụ N ể hiện

trong Hình 1.9, B cho phép biểu thị ớc (theo bit) của bộ đệm ứng dụng

củ , để cho Q biểu thị số bit mà ph đ ợ đệ ớc khi ứng dụng khách hàng bắ đầu phát sóng (Tất nhiên, Q <B.) r biểu thị mức tiêu thụ tố độ

video mà khách hàng rút bit ra khỏi bộ đệm ứng dụng khách hàng trong quá trình phát l i Vì vậy, ví dụ, nếu tố độ khung hình là 30 khung hình/giây, và mỗi (nén)

l 00 000 ,s đ r = 3 Mbps Chúng tôi sẽ bỏ qua bộ đệm g i và bộ

đệm nhận TCP

9 Phân tích bộ đệm y khách cho video streaming

Hãy gi định r ng các máy chủ sẽ g i bit với tố độ đổi x bất cứ khi

nào bộ đệm khách hàng l đầy (đây là một việ đ n hóa, vì t lệ g i TCP khác nhau do kiểm soát tắc nghẽn; chúng tôi sẽ kiểm tra thực tế tố độ phụ

thuộc thời gian x(t)) Gi s t i thờ đ ểm t = 0, các bộ đệm ứng dụng rỗng và

video bắ đầ đến với bộ đệm ứng dụng khách hàng Bây giờ chúng ta hỏi khi nào

thời gian phát sóng t = t p bắ đầ ? V ú đ ở đ , ời gian

nào t = t f bộ đệm ứng dụng khách hàng trở đầy?

T ớ , y định t p , thời gian khi Q đ ớc vào ứng dụng bộ

đệm và phát sóng bắ đầu Nhớ r đế ộ đệm ứng dụng khách hàng đến

tố độ x đ ợc lấy ra từ bộ đệ y ớc khi phát sóng bắ đầu

N ậy, l ợng thời gian cần thiế để xây dựng lên các bit Q (sự chậm trễ đệm đầu) là t p =Q / x

Bây giờ ú y định t f, đ ểm thời gian khi bộ đệm ứng dụng

khách hàng trở đầy ầu tiên chúng ta nhận thấy r ng nếu x <r ( l ,

nếu t lệ máy chủ g l lệ tiêu thụ ), s đ ộ đệm của khách

hàng sẽ không bao giờ trở đầy! Thật vậy, thời gian bắ đầu t p, bộ đệm sẽ bị

c n kiệt ở mức r và sẽ ch đ ợc thực hiện t i t lệ x <r Cuối cùng, bộ đệm khách

hàng ra sẽ hoàn toàn trống rỗng, lúc này video sẽ đ trên màn hình trong

khi bộ đệm khách hàng chờ đợi t p thêm ít y để xây dựng Q bit của video Vì

vậy, khi tố độ có sẵn trong m l s ới các tố độ video, phát sóng sẽ luân phiên gi a các thời kỳ phát sóng liên tục và thờ đ T ột

vấ đề khác, b n sẽ tìm hiểu thêm để đị độ dài của mỗi đ n phát sóng liên

tục và thờ đ l ột hàm của Q, r và x Bây giờ chúng ta xác định t f khi x> r T ờng hợp này, từ thời gian bắ đầu t p, sự gia của bộ

đệm từ Q tới B kể từ tố độ bit x- r đ ần c n kiệt ở tố độ r đ

có tố độ x, ể hiện trong Hình 1.9 Với nh ng gợi ý, b n sẽ tìm hiểu thêm

để định t f, thời gian bộ đệm của khách hàng trở đầy L ng khi có sẵn tố độ trong m ng là cao tố độ video, sau khi trì hoãn bộ đệ đầu,

ời dùng sẽ đ ợ ởng thức phát sóng liên tụ đến khi video kết thúc

1.3.2.4 Chấm dứt sớ và t định vị các video

Hệ thống HTTP s ờng s dụ đề HTTP byte-range trong yêu cầu tin nhắn HTTP G T, đ y định cụ thể ph m vi của byte khách hàng hiệ đ ốn lấy từ video mong muố ề y đ c biệt h u ích

ời dùng muố y đổi vị ( là nh y) đến mộ đ ể lai trong thời gian có trong video Khi s dụng l i vị đến một vị trí mới, khách hàng sẽ g i một yêu cầu HTTP mới, ch vớ đề byte-range từ đ y file cần các máy chủ g i d liệu Khi máy chủ nhậ đ ợc yêu cầu HTTP mới, nó

có thể đ ất kỳ yêu cầ ớ đ y i byte bắ đầu với các byte

đ ợc ch ra trong byte-range yêu cầu

Trong khi chúng tôi đề cập về vấ đề định vị, chúng tôi dành thời gian ngắ đề cập khi mộ ời s dụng l i vị đến mộ đ ể l video ho c chấm dứt video sớm, một số n ớ xem d liệu truyền qua các máy chủ sẽ d n đến không xem, gây l ng và

tài nguyên máy chủ Ví dụ, gi s r ng các bộ đệm khách hàng đầy với các bit B

t i một số thờ đ ểm t 0 vào các video, và t i thờ đ ểm này đ t l i vị ời s

dụng một số tức thời t > t 0 + B / r vào các , s đ để hoàn

thành từ thờ đ ể đ T ờng hợp này, tất c các bit B trong bộ đệm sẽ

m, tài nguyên máy chủ đ đ ợc s dụ để truyền t i các

bit B đ l C l đ ể trên m ng Internet do

chấm dứt sớm, mà có thể khá tố é , đ c biệt cho các liên kết không dây [31]

L đối vớ đ ều này, nhiều hệ thống truyền ch s dụng một bộ đệm ứng dụng khách hàng với ớc vừa ph i, ho c sẽ giới h n số l ợng video tìm n p

ớc b ng cách s dụ đề byte-range trong HTTP yêu cầu [3]

hệ thống này ở II

C Ư NG I T NG QU N V NG T NG VÀ ƯỚC Ư NG NG

THÔNG

ầ ày đề p đế ệ ơ ả ầ p ả u t đế tr g

t u t ướ lư g ă g t ô g đườ g truyề ụ ế tr truyề ữ l ệu t

y ủ tớ y ểu ột đườ g và đ đườ g ẽ đư đề p tớ tr g thích ứng Streaming và DASH ụ , thi hành thích ứ g tr g đ đường ụ Ng à r , tr g ươ g ũ g tr ày về định dạng video

ho c chấ l ợng cao T y , ú ần ph i biết r ng bitrate thấp sẽ

gi m sức ép với phần cứ ều này có thể sẽ trở nên quan trọ đối với các thiết

B n có thể biế đ ợ đ s dụng b ng cách truy cập vào

w s s để đ Kết qu nhậ đ ợc có thể đ ợ để so sánh với

đ ờng truyền khác Ở mộ ế giới, tố độ bitrate có thể l đến

1Gbps (1000 Mbps) Tuy nhiên, hầu hế ời dùng trên toàn cầu hiệ đ s dụng các m ng Internet với tố độ kết nối ch vài Mbps

2.1.4 RTT

Round-trip time (RTT) là kho ng thời gian tính từ lúc client bắ đầu g i request tới lúc nó nhận gói d liệ đầu tiên tr về, không bao gồm thời gian nhận đầy đủ d liệu

T yệ ế ố ớ ộ w s lầ đầ sẽ ố ể ba RTT: ộ RTT để ề ( NS), ộ RTT để ở ế ố TCP,

Trong các hệ thốn s ấp ho c thứ cấp, thời gian cần thiế để một tín

hiệu (pulse) đ ợc truyền tớ đ ệu ph n hồi (echo) ho c tín hiệu tr lời (transponder reply) quay l i tới thiết bị nhận

Thời gian trễ trọ ọng trong các hệ thống đ ỏi giao tiếp ều, chẳng h đ ện tho i tiếng nói, hay các hệ thống d

liệu s dụng tin báo nhận (ACK/NAK data system) – ời gian trọn vòng trực tiếp ở đến tố độ truyền d liệu (throughput rate), chẳng h n giao thức

TCP Thời gian trễ trọn vòng có thể tr i từ y đối với một hệ thống radio tầm ngắn (short line-of-sight), tới nhiều giây đồng hồ đối với một m đ liên kết với một ho c nhiều liên kết vệ tinh Nó bao gồm thời gian trễ t i nút m ng ờng truyền d ối với truyền thông TCP, thời gian trễ trọn vòng đ ợc tính từ quy trình bắt tay ba ớc b đ ời gian từ khi truyền

đ n (segment transmission) tới khi nhậ đ ợc tin báo nhận (ACK)

Thời gian RTT đ ợc minh họa qua hai đ ểm giao nhận sau:

2 ạ u đ ể g RTT chính là *Độ trễ đường truyền

Độ trễ đường truyền = Thời gian ACK g i thông báo t Host g i tới Host nh n Thời gian g i gói tin tại Host g i = Du g lư ng gói tin tính bằ g t Bă g t ô g đường truyền tính bằng bits trên giây

Thời gian g i xong gói tin = Thời gian g i gói tin tại Host g i +Số lần g i xong gói tin*RTT+3* Độ trễ đường truyền + Thời gian khởi động truyền nh n dữ liệu

3 ạ t ờ g g g g g t u đ ể g

2.1.5 Băng gốc

Một tín hiệ ốc có một d i tần rất hẹp, tức là mộ ờ độ quang phổ là khác không ch cho các tần số trong vùng lân cận của nguồn gốc (gọi là f=0) đáng kể ở nh T ễn thông và x lý tín hiệu, tín hiệ ố đ ợc truyề đ đ ều chế, l , ất kỳ sự

y đổi trong ph m vi tần số của tín hiệu, và có tần số thấp - chứ của tần số gầ 0 z đến một tần số cắ ố đ ốc

có thể đồ ới thông thấp ho đ ều chế, đ ợc phân biệt với d i , ss, s đ ều chế, tần số trung gian, ho c tần số vô tuyến (RF) Trong các m ng cục bộ, đ y l ộ pháp truyề , đ hiệu m đ ợ đ ực tiếp vào cáp trong d ng số đ ều biên Các tín hiệu máy tính có thể đ ợc truyền qua cáp b ng hai cách: tín hiệ ự (t biến) và tín hiệu số M ng truyề ự đ ợc gọi là m ộng (broadband network) Các m ng truyền thông số đ ợc gọi là m sở Vì các tín hiệu của máy tính là tín hiệu số, cho nên số l ợng m ch cần thiết cho một

m sở để truyền d n tín hiệu này ra vào máy tính là rấ H a, nhiều m sở có thể s dụng dây cáp hai sợi xoắ ( y đ ện tho i bình ờng), cho nên lắ đ t chúng giá rẻ ới m ộ đ ỏi ph i có cáp đồng trục Tuy nhiên, hệ sở bị h n chế về cự ly truyền d n và ch cho

phép thực hiện một kênh truyền thông trong một lúc Hầu hết các m ng máy tính cục bộ đều là m sở

2.1.6 Bộ đệm

Bộ đệm (BUFFER) là mộ đ ị của bộ nhớ đ ợc giao nhiệm vụ t m thời

l , đ c biệ l ờng hợp các bộ phận có tố độ cao ph i đợi cho các bộ phận có tố độ chậ đ ổi theo kịp Các thiết bị khác nhau không làm việc cùng tố độ, hệ đ ều hành thì x lý các tiến trình có chia thờ đ cần có bộ đệ để chứa t m thời Bộ đệm ho độ ế FIFO

2.1.7 Mạng máy tính và mô hình phân tầng

T ể đị M C ủ ộ y s ụ ệ đ ề W ws

ệ lệ f OS ớ số sw