1.3.1. Ứng dụng E-mail, FTP:
E-mail là một dịch vụ phổ biến nhất trờn Internet trước khi World Wide Web ra đời, nú được đưa ra để người sử dụng trờn mạng cú thể trao đổi cỏc thụng bỏo cho nhau trờn phạm vi thế giới. Bằng dịch vụ này, mọi người sử dụng mỏy tớnh kết nối với Internet đều cú thể trao đổi thụng tin với nhau. Đõy là một dịch vụ mà hầu hết cỏc mạng diờn rộng đều cài đặt và cũng là dịch vụ cơ bản nhất của một mạng khi gia nhập Internet. Nhiều người sử dụng mỏy tớnh tham gia mạng chỉ dựng duy nhất dịch vụ này. Dịch vụ này sử dụng giao thức SMTP (Simple Mail Transfer Protocol) trong họ giao thức TCP/IP.
Một điểm mạnh của thưđiện tử là nú là phương thức trao đổi thụng tin nhanh chúng và thuận tiện. Người sử dụng cú thể trao đổi những bản tin ngắn hay dài chỉ bằng một phương thức duy nhất. Rất nhiều người sử dụng thường truyền tập tin thụng qua thư điện tử chứ khụng phải bằng cỏc chương trỡnh truyền tập tin thụng thường. Đặc điểm của dịch vụ thưđiện tử là khụng tức thời (off-line) - tất cả cỏc yờu cầu gửi đi khụng đũi hỏi phải được xử lý ngay lập tức. Khi người sử dụng gửi một bức thư, hệ thống sẽ chuyển thư này vào một vựng riờng (gọi là spool) cựng với cỏc thụng tin về người gửi, người nhận, địa chỉ mỏy nhận... Hệ thống sẽ chuyển thư đi bằng một chương trỡnh khụng đồng bộ (background). Chương trỡnh gửi thư này sẽ xỏc định địa chỉ IP mỏy cần gửi tới, tạo một liờn kết với mỏy đú. Nếu liờn kết thành cụng, chương trỡnh gửi thư sẽ chuyển thư tới vựng spool của mỏy nhận. Nếu khụng thể kết nối với mỏy nhận thỡ chương trỡnh gửi thư sẽ ghi lại những thư chưa được chuyển và sau đú sẽ thử gửi lại một lần nú hoạt động. Khi chương trỡnh gửi thư thấy một thư khụng gửi được sau một thời gian quỏ lõu (vớ dụ 3 ngày) thỡ nú sẽ trả lại bức thư này cho người gửi. Với cơ chế hoạt động như trờn thỡ rừ ràng đối với dịch vụ E- mail khụng đũi hỏi yếu tố thời gian thực do vậy yờu cầu QoS đũi hỏi khụng quỏ lớn.
Khi mạng xẩy ra tắc nghẽn cỏc mail cú thể ngừng chuyển đi mà cú thểđợi khi mạng rỗi trở lại thỡ thực hiện truyền đi. Tuy nhiờn một yờu cầu đối vơi E-mail đú là độ tin cậy, cỏc gúi gửi đi phải đảm bảo đến đớch và nội dung cần phải chớnh xỏc hũan toàn. Do vậy đũi hỏi mạng khụng bị mất gúi, hoặc khi cú xẩy ra mất gúi thỡ phải cú cơ chế truyền lại an toàn do vậy E-mail sử dụng TCP.
FTP (File Transfer Protocol) là giao thức truyền một file từ một host tới một host khỏc. Hỡnh 1.2 diễn tả tổng quan về FTP
Hỡnh 1.2: FTP truyền file giữa cỏc hệ thống
Dịch vụ FTP cú những yờu cầu giống với dịch vụ E-mail về chất lượng truyền dẫn, nú khụng đũi hỏi nhiều vềđộ trễ hay jitter, cỏc file cú thểđến đớch nhanh khi cú nhiều băng thụng hay chậm khi băng thụng bị hạn chế nhưng quan trọng cỏc gúi nhận được phải đầy đủ và khụng cú lỗi. FTP cũng sử dụng giao thức TCP để khi cú mất gúi hay lỗi gúi thỡ cú sự truyền lại.
1.3.2. Ứng dụng Streaming, õm thanh hỡnh ảnh lưu trước:
Cú rất nhiều ứng dụng khỏc nhau chạy trờn nền mạng Internet như Streaming, Stored Audio và video. Trong cỏc ứng dụng này, cỏc client đưa ra yờu cầu cỏc file õm thanh hỡnh ảnh nộn được lưu trữ trong mỏy chủ. Cỏc file õm thanh được lưu trước cú thể gồm thu thanh bài giảng của một giỏo sư, một bài hỏt, một bản giao hưởng, nội dung từ một kờnh radio quảng bỏ, hoặc một đoạn ghi õm lịch sử. Cỏc file video
Truy n file FTP server Giao tiếp người dựng FTP FTP client Người dựng tại trạm Server File hệ thống local File hệ thống remote
được lưu trước cú thể gồm cú cỏc video về một bài giảng của giỏo sư, đủ một bộ phim, cỏc chương trỡnh tivi đó ghi lại từ trước, phim tài liệu, cỏc hỡnh ảnh về cỏc sự kiện lịch sử, cỏc clip nhạc hỡnh hay hoạt hỡnh. Cú ba đặc tớnh quan trọng để phõn biệt cỏc lớp ứng dụng này.
Stored Media: cỏc nội dung media đó được ghi trước và được lưu tại mỏy chủ. Do vậy, người dựng cú thể tạm dừng, tua lại và tua nhanh cũng như chọn điểm em của chương trỡnh. Thời gian từ khi một client đưa ra yờu cầu đến khi hỡnh ảnh hiện ra tại client vào khoảng 1 tới 10 giõy là cú thể chấp nhận được.
Streaming: Trong hầy hết cỏc ứng dụng õm thanh, hỡnh ảnh một mỏy khỏch bắt đầu hiển thị cỏc õm thanh hỡnh ảnh sau khi nú nhận file từ mỏy chủ. Bằng cỏch này mà mỏy khỏch sẽ hiển thịđược hỡnh ảnh, õm thanh từ chỗ trong file trong khi nú vẫn nhận phần cũn lại của file từ mỏy chủ. Kỹ thuật này gọi là streaming, để trỏnh việc phải dowload toàn bộ file (và phải chịu độ trễ lớn) trước khi bắt đầu hiển thị ra. Cú nhiều sản phẩm phần mền phục vụ cho streaming đa phương tiện, gồm cú RealPlayer của hóng RealNetwork vàWindows Media của Microsoft. Tuy nhiờn cũng cú cỏc ứng dụng như Napster yờu cầu tũan bộ file phải được dowload trước khi bắt đầu hiện thị.
Continuous phayout: Khi bắt đầu hiển thị một hỡnh ảnh, nờn bắt đầu dựa vào định thời gốc của hỡnh ảnh. Cỏch này tạo ra một độ trễđỏng kể cho việc phõn phỏt dữ liệu. Dữ liệu phải được nhận từ mỏy chủ kịp thời cho việc hiển thị ở mỏy khỏch; ngược lại thỡ mọi thứ trở nờn vụ nghĩa. Trễn end to end là bắt buộc đối với streaming, stored media thường ớt liờn tục hơn so với cỏc chương trỡnh trực tuyến, cỏc ứng dụng tương tỏc như là thoại trờn internet và hội nghị truyền hỡnh.
1.3.3. Ứng dụng Streaming cho õm thanh, hỡnh ảnh sống
Lớp ứng dụng này tương tự như cỏc chương trỡnh radio và tive quản bỏ cổ điển, ngoại trừ việc truyền dẫn là thụng qua Internet. Cỏc ứng dụng này cho phộp một người dựng nhận live radio hoặc tivi truyền từ bất cứ nơi nào trờn thế giới. Cú thể xen trờn Yahoo !Broadcast 2000 và Netradio 2000 trờn Internet.
Bởi vỡ streaming của õm thanh hỡnh ảnh sống khụng được lưu trước, một mỏy khỏch khụng thể tua nhanh. Hơn nữa với phần dữ liệu đó được lưu trong bộ nhớ của mỏy khỏch, thỡ cỏc hành động tương tỏc như là dừng và tua lại là cú thể thực hiện ở một số ứng dụng. Cỏc ứng dụng sống, quảng bỏ online thường cú nhiều mỏy khỏch nhận cựng một chương trỡnh. Việc phõn bố õnh thanh/ hỡnh ảnh tới nhiều nơi nhận cú thểđạt được bằng kỹ thuật multicast.
1.3.4. Ứng dụng Hỡnh ảnh õm thanh tương tỏc thời gian thực
Lớp ứng dụng này cho phộp người dựng sử dụng õm thanh hỡnh ảnh để kết nối với người khỏc theo thời gian thực. Âm thanh tương tỏc thời gian thực thường được đề cập tới là điện thoại Internet, theo quan điểm từ phớa người dựng, nú tương đương như dịch vụ điện thoại chuyển mạch kờnh cổ điển. Điện thoại internet cú thể cung cấp bằng cỏc tổng đài nội bộ PBX, dịch vụđiện thoại đường dài với giỏ cả thấp. Nú cũng cung cấp cả dịch vụ tớch hợp điện thoại mỏy tỡnh, kết nối nhúm thời gian thực, cỏc dịch vụ chuyển huớng, định danh người gọi, lọc người gọi và nhiều dịch vụ khỏc. Hiện nay đó cú nhiều sản phẩn điện thoại Internet. Với cỏc video tương tỏc hay cũn gọi là hội nghị truyền hỡnh thỡ cú sản phẩm NetMeeting của Microsoft. Chỳ ý rằng cỏc ứng dụng õm thanh hỡnh ảnh tương tỏc, một user cú thể núi hoặc di chuyển bất cứ lỳc nào. Với một cuộc hội thoại tương tỏc giữa nhiều người, trễ từ lỳc một người núi và di chuyển cho tới khi hành động đú được chuyển tới đầu nhận nờn nhỏ hơn một vài trăm ms. Với õm thanh, độ trễ nhỏ hơn 150ms là khụng thể cảm nhận được đối với người nghe. Độ trễ từ 150ms tới 400ms là cú thể chấp nhận được, và độ trễ lớn hơn 400ms là cú thể dẫn đến cuộc hội thoại mà cỏc bờn khụng hiểu nhau núi gỡ.
1.3.5. Vớ dụ vềđiện thoại VOIP:
Tầng IP cung cấp cỏc dịch vụ best-effort. Với best-effort cỏc gúi được truyền đi từ nguồn tới đớch một cỏch nhanh nhất cú thể. Hơn nữa, best-effort khụng đảm bảo bất cứđiều gỡ về độ trễ end to end của cỏc gúi, hay biến động trễ hay việc mất gúi trong luồng dữ liệu.
Cỏc ứng dụng đa phương tiện tương tỏc thời gian thực, như là điện thoại internet và hội nghị truyền hỡnh thời gian thực thường rất nhẩy cảm với trễ gúi, biến
động trễ và mất gúi. Chớnh vỡ vậy cần phải cú cỏc kỹ thuật để đảm bảo cỏc ứng dụng õm thanh hỡnh ảnh khi truyền qua mạng mà cỏc giỏ trị về trễ, jitter và mất gúi khụng vượt quỏ mức quy định. Chỳng ta sẽ xem xột một kỹ thuật trong ngữ cảnh là ứng dụng điện thoại Internet và trong hội nghị truyền hỡnh thời gian thực thỡ cũng tương tự.
Một người gọi điện trong ứng dụng VOIP sinh ra một tớn hiệu õm thanh gồm cú khoảng cú õm và cỏc khoảng lặng. Để tiết kiệm băng thụng, ứng dụng điện thoại internet chỉ sinh ra cỏc gúi trong khi núi. Trong khi núi người gửi sinh ra cỏc byte với tốc độ 8Kbyte/s, và cứ 20 ms người gửi tập hợp cỏc byte thành cỏc đoạn. Bởi vậy, số lượng byte trong một đoạn là (20ms).(8byte)=160 byte. Một đoạn mào đầu được gắn vào mỗi đoạn. Cỏc đoạn và mào đầu của nú được đúng gúi trong khung UTP, rồi cỏc khung UTP được gửi tới giao diện Socket. Bởi vậy trong quỏ trỡnh núi, một khung UTP được gửi định kỳ 20ms.
Nếu như mỗi gúi truyền tới phớa nhận với độ trễ cốđịnh, cỏc gúi được nhận ở phớa người nghe định kỳ 20ms trong quỏ trỡnh núi. Trong điều kiện lý tưởng, phớa nhận cú thể nghe lại cỏc đoạn một cỏch đơn giản. Nhưng, một số gúi cú thể bị mất và cỏc gúi sẽ khụng cú cựng độ trễ, đặc biệt trong khi xẩy ra tắc nghẽn trờn mạng. Vỡ vậy phớa nhận phải quan tõm tới việc xỏc định khi nào diễn tả lại đoạn và xỏc định làm gỡ với cỏc đoạn mất.
Hạn chế của dịch vụ Best-effort
Nhưđó đề cập dịch vụ best-effort cú thể dẫn đến mất gúi, trễ lớn và biến động trễ lớn. Bõy giời ta sẽ xem xột vấn đề này một cỏch chi tiết hơn
Mất gúi: Giả sử một khung UDP được sinh ra bởi ứng dụng VOIP. Cỏc khung UDP được đúng gúi trong IP packet. Khi cỏc packet truyền đi trong mạng, nú phải đi qua cỏc buffer (hành đợi) trong cỏc router đểđi tới đường ra. Hoàn toàn cú thể là một hoặc nhiều hàng đợi trong router bịđầy và khụng thể tiếp nhận cỏc IP packet. Trong trường hợp này, cỏc IP packet sẽ bị loại bỏ và phớa nhận sẽ khụng thể nhận được.
Mất gúi cú thể loại bỏ bằng cỏch gửi cỏc gúi thụng qua TCP mà khụng dựng UDP. Bởi TCP truyền lại cỏc gúi khụng nhận được từ phớa đớch. Hơn nữa, kỹ thuật
truyền lại khụng phự hợp với cỏc ứng dụng tương tỏc thời gian thực như là VOIP bởi vỡ chỳng sẽ tăng độ trễ. Hơn nữa, bởi vỡ đặc tớnh điều khiển tắc nghẽn của TCP, sau khi gúi mất tốc độ truyền tại phớa gửi cú thể giảm và làm cho tốc độ này nhỏ hơn tốc độở phớa nhận. Điều này cú thể cú một số trở ngại trong vấn đề nhận dạng õm thanh tại phớa thu. Với lý do đú, hầu hết cỏc ứng dụng VOIP thường chạy trờn UDP và khụng thực hiện việc truyền lại gúi tin. (adsbygoogle = window.adsbygoogle || []).push({});
Thực ra vấn đề mất gúi khụng nghiờm trọng như chỳng ra nghĩ. Thực ra, tỷ lệ mất gúi nằm trong khoảng từ 1% đến 20% cú thể chấp nhận được, dựa vào cỏch mà õm thanh mó húa và truyền đi, và cỏch mà mất gúi cú thể che giấu ở phớa thu. Vớ dụ, forward error correction (FEC) cú thể giỳp cho việc che giấu được sự mất gúi. Với FEC, cỏc thụng tin dư thừa được truyền cựng với thụng tin gốc để mà một số dữ liệu gốc lỗi cú thể khụi phục lại từ cỏc dữ liệu dư thừa. Tuy nhiờn, nếu một hoặc một số đường link giữa người nhận và người gửi cú tắc nghẽn, cỏc gúi mất vượt quỏ 20% thỡ khú cú thểđảm bảo chất lượng õm thanh.
Trễ end to end:
Trễ end to end là gồm cú trễ xử lý và trễ hàng đợi trờn router, trễ lan truyền, và cỏc trễ xử lý tại đầu cuối dọc theo đường từ nguồn tới đớch. Với những ứng dụng tương tỏc cao, như là VOIP, trễ end to end nhỏ hơn 150ms thỡ người nghe sẽ khụng cảm nhận được; trễ giữa 150ms và 400ms cú thể chấp nhận được nhưng chưa lý tưởng; và trễ vượt quỏ 40 ms sẽ làm hỏng cỏc cuộc hội thoại tương tỏc bằng õm thanh.
Biến động trễ :
Một thành phần chủ yếu đối với trễ end to end là trễ hành đợi ngẫu nghiờn trong một router. Bởi vỡ trễ là khỏc nhau trong mạng, thời gian từ lỳc một gúi được sinh ra ở nguồn cho đến khi nú nhận ở phớa thu cú thể giao động giữa cỏc gúi với nhau. Hiện tượng này được gọi là jitter.
Một vớ dụ, giả sử hai gúi liờn tiếp nhau trong lỳc phỏt tiếng núi đi vào ứng dụng VOIP. Người gửi gửi gúi thứ hai 20ms sau khi gửi gúi thứ nhất. Nhưng ở phớa nhận, khoảng thời gian giữa cỏc gúi cú thể lờn đến hơn 20ms. Để làm rừ điều này, giả
sử gúi đầu tiờn ở gần hàng đợi trống của router, nhưng sau khi gúi thứ nhất rời đi thỡ tại hàng đợi cú nhiều gúi từ nguồn khỏc đến cựng hàng đợi đú. Do vậy gúi thứ hai phải chịu độ trễ hàng đợi lớn hơn, gúi thứ nhất và thứ hai trở nờn xa nhau hơn 20ms. Khoảng thời gian giữa cỏc gúi cũng cú thể nhỏ hơn 20ms. Để thấy rừ điều này, lại giả sử hai gúi liờn tiếp trong đú gúi thứ nhất đi vào phần cuối của hàng đợi với một số lượng lớn cỏc gúi, và gúi thứ hai đến hàng đợi trước khi cỏc gúi từ nguồn khỏc tới. Trong trường hợp này, hai gúi đang xột sẽ ở gần kề nhau trong hàng đợi. Nếu như thời gian để truyền một gúi trong đi ra ngoài nhỏ hơn 20ms thỡ gúi thứ nhất và thứ hai sẽ cỏch nhau khoảng thời gian nhỏ hơn 20ms.
Nếu như phớa nhận bỏ qua sự tồn tại của jitter, và khụi phục cỏc đoạn như là những gỡ nhận được, khi đú sẽ dẫn đến chất lượng õm thanh trở nờn khụng nhận ra tại phớa thu. Tuy nhiờn jitter cú thể được loại bỏ bằng cỏch sử dụng sequence number, timestamps và plauout delay.
Loại bỏ jitter tại đầu thu đối với õm thanh
Đối với ứng dụng õm thanh như VOIP hoặc õm nhạc theo yờu cầu, phớa nhận nờn cung cấp khả năng phỏt đồng bộ cỏc đoạn õm thanh khi mà vẫn tồn tại jitter mạng. Điều này thực hiện được bằng việc kết hợp ba kỹ thuật sau :
Gỏn vào mỗi đoạn một số liờn tục. Người gửi tăng dóy số liờn tục lờn một đối với cỏc gúi tin sinh ra.
Gỏn cho mỗi đoạn một nhón thời gian. Phớa gửi gỏn mỗi đoạn một thời gian cho mỗi đoạn được sinh ra.
Hiển thị trễ cỏc đoạn ở phớa nhận. Hiển thị trễ cỏc đoạn õm thanh nhận được phải đủ dài để cho cỏc gúi nhận được trước khi lờn lịch hiển thị. Trễ hiển thị cú thể được cố định trong khoảng thời gian trong suốt toàn bộ thời gian hội nghị, hoặc cú thể thay đổi tựy biến trong thời gian hội nghị. Cỏc gúi khụng đến được trước khi thời