Thứ Năm, 21 tháng 3, 2013
Principles of Reliable Data Transfer
Trong phần này chúng ta cùng suy ngẫm về vấn đề truyền tải đáng tin trong một context chung. Điều đó là hợp lý bởi vì bởi vì vấn đề implementing reliable data transfer (rdt) không chỉ diễn ra tại transport layer, cũng như là application layer. Với một kênh truyền tải đáng tin cậy, không một dữ liệu chuyển đi nào bị hư (corrup) (lật từ 0 sang 1 hay ngược lại) hoặc bị mất và tất cả được vận chuyển theo đúng thứ tự như chúng được gửi. Đó rõ ràng là một service model cung cấp bởi TCP đến các Internet applications yêu cầu nó (TCP).
Thứ Tư, 20 tháng 3, 2013
Modules and packages in Python
1. Modules
Khi tiếp xúc với Python chắc hẳn chúng ta bắt gặp nhiều modules, vậy modules là gì ? Module là một thành phần cung cấp cho Python định nghĩa về các hàm, các biến, các lớp, tất cả đều tương ứng với một chủ đề đã xác định trước. tất cả các definitions được chứa trong một file Python. Dành lời cảm ơn chân tình đến module, nhờ nó mà ta có thể tái sử dụng lại các definitions trong chương trình của mình. Python khuyến khích bạn xây dựng những module cho chính mình với những cách đơn giản nhất.
1.1 Sử dụng modules
Để sử dụng modules bạn phải sử dụng câu lệnh import. Chúng ta cùng xét một ví dụ. Python chứa đựng rất nhiều modules trong nó, một trong số những module rất hữu dụng đó là sys module (sys là viết tắt của từ system). Nó cung cấp các thông tin liên quan đến hệ thống khi chạy và môi trường chạy. Ngoài ra Python sys module cung cấp khả năng truy cập đến bất cứ command line arguments thông qua sys.argv. Nó phục vụ hai mục đích chính sau:
- sys.argv là một danh sách của command-line arguments.
- len(sys.argv) là số lượng của command-line arguments.
ở đây sys.argv[0] là chương trình ví dụ script name
Khi tiếp xúc với Python chắc hẳn chúng ta bắt gặp nhiều modules, vậy modules là gì ? Module là một thành phần cung cấp cho Python định nghĩa về các hàm, các biến, các lớp, tất cả đều tương ứng với một chủ đề đã xác định trước. tất cả các definitions được chứa trong một file Python. Dành lời cảm ơn chân tình đến module, nhờ nó mà ta có thể tái sử dụng lại các definitions trong chương trình của mình. Python khuyến khích bạn xây dựng những module cho chính mình với những cách đơn giản nhất.
1.1 Sử dụng modules
Để sử dụng modules bạn phải sử dụng câu lệnh import. Chúng ta cùng xét một ví dụ. Python chứa đựng rất nhiều modules trong nó, một trong số những module rất hữu dụng đó là sys module (sys là viết tắt của từ system). Nó cung cấp các thông tin liên quan đến hệ thống khi chạy và môi trường chạy. Ngoài ra Python sys module cung cấp khả năng truy cập đến bất cứ command line arguments thông qua sys.argv. Nó phục vụ hai mục đích chính sau:
- sys.argv là một danh sách của command-line arguments.
- len(sys.argv) là số lượng của command-line arguments.
ở đây sys.argv[0] là chương trình ví dụ script name
Vấn đề về ghép và tách kênh
Trong phần này chúng ta sẽ thảo luận về vấn đề ghép kênh và tách kênh tại lớp truyền tải. Đó là một dịch vụ vận chuyển mở rộng host to host được cung cấp bởi network layer đến dịch vụ vận chuyển host to host của các ứng dụng chạy trên các hosts. Để giữ các vấn đề thảo luận đạt mức cụ thể, chúng ta sẽ thảo luận về các dịch vụ cơ bản của lớp truyền tải trong môi trương Internet. Chúng tôi nhấn mạnh rằng, dịch vụ ghép và tách kênh là cần thiết cho tất cả các kiểu mạng máy tính.
Ở host đích, lớp truyền tải nhận các segments từ lớp mạng phía dưới. Lớp vận tải có nhiệm vụ vận chuyển dữ liệu trong các segments đến các process ứng dụng thích hợp đang chạy trên host. Nào hãy cùng nhìn vào một ví dụ. Giả sử bạn đang ngồi trước máy tính và download Web pages trong khi đang chạy một phiên FTP và hai phiên Telnet. Do đó bạn có 4 processes ứng dụng đang chạy trên máy của mình- 2 processes Telnet, 1 process FTP và 1 process Http. Trong khi lớp truyền tải trên máy tính của bạn nhận dữ liệu từ lớp mạng bên dưới nó cần định hướng dữ liệu của bạn đến một trong 4 ứng dụng. Nào hãy cùng nhau phân tích làm sao để nó làm được điều này.
Chúng ta biết rằng mỗi process có thể có một hoặc nhiều sockets, những cái cửa mà dữ liệu từ process đi qua rồi tới lớp mạng. Lớp transport tại host nhận sẽ không thực sự vận chuyển dữ liệu trực tiếp đến các process, thay vào đó nó chuyển đến các socket trung gian. Bởi vì trong một khoảng thời gian cho trước có thể có nhiều hơn một socket tại host nhận, mỗi socket sẽ có một số định danh duy nhất. Định dạng của các định danh (identifier) phụ thuộc vào socket đó là UDP hay TCP socket.
Nào hãy cùng suy ngẫm thử xem làm thế nào để các host nhận có thể định hướng trực tiếp các segments tới (incoming segments) đến socket thích hợp. Mỗi transport-layer segment có một tập hợp các trường trong segment để làm nhiệm vụ này. ở host nhận, transport layer sẽ thực hiện việc phân tích các segment để nhận dạng được các socket đích và chuyển segment tới socket đó. Công việc của việc vận chuyển dữ liệu trong transport layer segment đến đúng socket cần nhận được gọi là tách kênh. Công việc thu gôm dữ liệu tại host nguồn từ các nguồn socket khác nhau và đóng gói mỗi data chunk với thông tin header(được sử dụng khi tách kênh) để tạo các segments và chuyển tiếp các segments đên lớp mạng được gọi là ghép kênh. Lớp truyền tải sở dĩ tách kênh các segments đến các process thích hợp là do việc direct các dữ liệu trong segment đến (arriving segment's data ) đên các sockets thích hợp. Những host trung gian còn phải thu thập các dữ liệu ra từ các sockets, form các transport layer segment, và chuyển các segments đi xuống lớp mạng. Mặc dù được giới thiệu ghép kênh và tách kênh trong môi trường Internet, điều quan trọng là bạn nhận ra rằng chúng (ghép kênh và tách kênh) liên quan đến hầu hết giao thức nào là duy nhất đặt tại một layer (ví dụ như transport layer) được sử dụng bởi nhiều giao thức lớp trên.
Để hiểu về công việc tách kênh, ta nhắc lại về khái niệm tương tự : hộ gia đình. Mỗi đứa trẻ được nhận dạng bởi tên của cậu bé hay cô bé đó. Khi Bill nhận được một bó các mails từ mail carrier, anh ấy thực hiện công việc ''tách kênh'' thông qua việc quan xét xem ai được đánh địa chỉ trong bức thư và sau đó chuyển thư đến cho chị hay anh của anh ấy. Ann thực hiện việc ghép kênh khi cô ấy thu các mail từ chị và anh của cô ấy và gửi cho mail person.
Nào bây giờ chúng ta đã hiểu về việc ghép kênh và tách kênh tại lớp truyền tải, chúng ta hãy cùng phân tích làm thế nào chúng được hoàn thành trong host. Chúng ta biết răng transport-layer multiplexing yêu cầu các sockets có các định danh duy nhất (1). và mỗi segment có những trường đặc biệt để chỉ ra cho socket biết segments nào được vận chuyển. Các trường đặc biết đó là source port number field và destination port number field (đối với từng trường hợp TCP và UDP sẽ có những trường khác nhau). Mỗi chỉ số port là một số 16 bit chạy từ 0 đến 65535, các ports từ 0 - 1023 được gọi là các well-known port numbers và được hạn chế sử dụng, có nghĩa là các port này được sử dụng cho các ứng dụng well-known như là HTTP(80), FTP(21). Danh sách các ports nổi tiếng bạn có thể tham khảo trong RFC 1700 và được cập nhật trong RFC 3232. Khi chúng ta phát triển một ứng dụng chúng ta phải gán port ứng dụng.
Bây giờ rõ ràng bạn nên biết: Làm thế nào để transport layer có thể triển khai một ứng dụng tách kênh: Mỗi socket trong host có thể được gắn một port number, và khi segment đi tới một host, transport layer sẽ phân tích địa chỉ port đích trong segment và direct segment đó đên socket tương ứng. Dữ liệu của segment có thể băng qua socket để tìm tới process được dán vào socket đó. Như ta có thể thấy đó là cách UDP làm, riêng đối với TCP việc ghép tách kênh mang màu sắc tinh tế hơn.
Connectionless Multiplexing and Demultiplexing
Nhắc lại trong chương trước, một chương trình Java chạy trên host có thể tạo một UDP socket với dòng dưới đây:
DatagramSocket mySocket = new DatagramSocket();
Khi một UDP socket được tạo theo cách trên thì thì transport layer tự động gán một port number đến socket. Cụ thể hơn, transport layer sẽ gắn các port từ 1024 đến 65535 đến socket với một chú ý nhỏ rằng port được gán hiện không được sử dụng bởi socket nào khác trên host. Một sự thay thế, Java có thể tạo một UDP socket theo cách sau đây:
DatagramSocket mySocket = new DatagramSocket(19157);
Trong trường hợp này ứng dụng gán một port được chỉ định, 19157 đến UDP socket. Nếu người dụng viết code để triển khai một ứng dụng sử dụng "well-known protocol" khi đó người viết ứng dụng phải gán một giá well-known port number tương ứng. Về phía client các port sẽ tự động được gán trong khi tại phía server các port được chỉ định.
Với các port numbers được gán đến UDP sockets ta có thể mô tả chính xác định quá trinh UDP Multiplexing/ Demultiplexing. Giả sử process trong host A với UDP port number là 19157 muốn gửi một khối dữ liệu ứng dụng tới process với UDP port number là 46428 tại host B. Transport layer trong host A sẽ tạo một transport layer segment chứa dữ liệu của ứng dụng (application data), source port 19157 và destination port 46428 và 2 giá trị khác (sẽ được thảo luận sau). transport layer sau đó chuyển segment kết quả (the result segment) đến network layer. network layer sau đó đóng gói (encapsulate) segment trong IP datagram và tạo ra những điều kiện tốt nhất để vận chuyển segment tới host nhận. Nếu segment đến tại host nhận B, transport layer trong host nhận sẽ kiểm tra destination port number trong segment(46428) và vận chuyển segment đến socket của nó nhận dạng bởi port 46428. Chú ý rằng tại host B có thể chạy nhiều process với mỗi process sẽ có UDP socket cũng như port number tương ứng của riêng nó. Như đã biết khi các UDP segments đến từ mạng, host B sẽ direct (demultiplexing) mỗi segment đến nhưng socket tương xứng với nó thông qua việc kiểm tra destination port number.
Một điều quan trọng cần ghi chú đó là UDP socket hoàn toàn được định danh bởi một bộ destionation IP address và destination port number. Kết quả cho thấy, nếu 2 UDP segments có source IP address và/ hoặc source port number nhưng có chung destination IP address và destionation port number khi đó 2 segments sẽ được directed đến cùng một destionation process qua cùng một destination socket.
Chúng ta có thể tự hỏi ? Mục đích của source port number để làm gì ? Ví dụ trong A-to-B segment (segment gửi từ A đến B) source port number phục vụ như là một "return address"- Khi B muốn gửi segment ngược lại cho A, destination port trong B-to-A segment sẽ là source port number trong A-to-B segment (Địa chỉ đầy đủ trả về bao gồm địa chỉ IP nguồn của A và source port number). Trong UDPServer.java, server sử dụng một phương thức để extract source port number trong segment nó nhận được từ phía client, với source port number vừa extract được ở trên sẽ được sử dụng làm destination port number trong segment kế tiếp.
Connection-Oriented Multiplexing and Demultiplexing
Để hiểu về TCP demultiplexing , chúng ta cần quan sát kĩ TCP socket và TCP connection establishment (thiết lập kết nối TCP) . Một sự khác biệt tinh tế giữa TCP socket và UDP socket đó là TCP socket được định dạng bởi bộ bốn (four-tuple): (source IP address, source port number, destination IP address, destination port number). Do vậy, khi TCP segment đi từ network đến host, host sử dụng cả thẩy 4 giá trị để direct (demultiplex) segment đến socket thích hợp. Cụ thể hơn, trái ngược với UDP, 2 segments đến với địa IP source khác nhau hoặc source port numbers sẽ (với ngoại lệ là các TCP segment mang yêu cầu thiết lập kết nối ban đầu ( the original connection-establishment request) ). Được direct đến hai sockets khác nhau. Để có được cái nhìn cụ thể hơn. Hãy cùng suy ngẫm về TCP client-server programming
- TCP server application có một "welcoming socket " , những gì chờ đợi các connection-establishment requests từ phía TCP clients trên một port number, giả sử là 6789
- TCP client sẽ sinh ra một segment thiết lập kết nối (connection-establishment segment) với dòng sau
Socket clientSocket = new Socket ("serverHostName", 6789);
-Một request thiết lập kết nối đơn thuần chỉ là một TCP segment với destination port number 6789 và một bit đặc biệt trong TCP header phục vụ cho việc thiết lập kết nối. Segment còn bao gồm cả source port number, những gì được chọn bởi client. Dòng phía trên tạo một TCP socket cho client process, thông qua đó những data có thể được enter và rời khỏi client process.
- Khi hệ điều hành của host chạy server process nhận được một yêu cầu kết nối đến (incoming-connection request ) với destination port là 6789, nó xác định server process đang đợi để chấp nhận kết nối trên port 6789. Server process sau đó tạo ra một new socket:
Socket connectionSocket = welcomeSocket.accept()
- transport layer tại server ghi chú 4 giá trị trong connection-request segment: (1) source port number trong segment, (2) địa chỉ IP của host nguồn, (3) destination port number trong segment, (4) địa chỉ IP của chính nó. socket mới được tạo ra được nhận dạng bởi 4 giá trị trên. Tất cả các segments sau đó nếu match tất cả 4 giá trị trên sẽ được demultiplexed đên socket đó. Với TCP connection như trên, client và server có thể gửi dữ liệu cho nhau.
Server host có thể support nhiều TCP sockets đồng thời, với mỗi socket được gắn với một process, và mỗi socket được nhận dạng bởi four-tuple nêu trên. Khi một TCP segment đến host tất cả 4 trường (source IP address, source port, destination port number, destionation IP address) được sử dụng để direct (demultiplex) segment đến socket thích hợp.
Web Servers and TCP
Trước khi kết thúc bài thảo luận, thật hữu ích khi chúng ta nói một chút về Web servers và chúng sử dụng các port numbers như thế nào ?. Suy ngẫm, một host đang running một Web server, ví dụ như Apache web server, trên cổng 80. Khi clients (ví dụ như browsers) gửi các segments đến server, tất cả segments sẽ có destination port 80. Cụ thê hơn, cả các segments khởi động kết nối (initial connection-establishment segments) và các segments mang các HTTP request messages sẽ có destination port 80. Như đã mô tả trên, server sẽ phân biệt các clients khác nhau bằng cách sử dụng source IP address và source port numbers.
Web server sẽ sinh ra một new process cho mỗi kết nối, mỗi trong processes có connection socket riêng của nó, những gì HTTP requests đi tới và HTTP responses được gửi đi. Tuy nhiên không hẳn chỉ tồn tại một sự tương ứng one-to-one giữa connection sockets và processes. Các high performing Web servers ngày nay thường chỉ sử dụng một process và tạo một new thread với new connection socket cho mỗi client connection (thread có thể được nhìn nhận như một tiến trình con gọn nhẹ). Đối với server như trên, tại một thời gian cho trước có nhiều connection sockets (với các định danh (identifiers) khác nhau) gắn vào cùng một process.
Nếu client và server đang sử dụng sử dụng persistent HTTP(HTTP lâu dài), sau đó trong suốt quá trình của persistent connection nếu client và server trao đổi các HTTP messages thông qua cùng một server socket. Tuy nhiên, nếu client và server sử dụng non-persistent socket, một new TCP connection sẽ được tạo và đóng đối với mỗi request/response và hiển nhiên đi kèm nó là mỗi new socket connection được tạo cho mỗi request/response. Việc thường xuyên tạo và đóng các sockets có thể ảnh hưởng đến performance của các busy Web server (mặc dù cũng có những mẹo về hệ điều hành có thể giúp giảm thiểu điều này )
Ở host đích, lớp truyền tải nhận các segments từ lớp mạng phía dưới. Lớp vận tải có nhiệm vụ vận chuyển dữ liệu trong các segments đến các process ứng dụng thích hợp đang chạy trên host. Nào hãy cùng nhìn vào một ví dụ. Giả sử bạn đang ngồi trước máy tính và download Web pages trong khi đang chạy một phiên FTP và hai phiên Telnet. Do đó bạn có 4 processes ứng dụng đang chạy trên máy của mình- 2 processes Telnet, 1 process FTP và 1 process Http. Trong khi lớp truyền tải trên máy tính của bạn nhận dữ liệu từ lớp mạng bên dưới nó cần định hướng dữ liệu của bạn đến một trong 4 ứng dụng. Nào hãy cùng nhau phân tích làm sao để nó làm được điều này.
Chúng ta biết rằng mỗi process có thể có một hoặc nhiều sockets, những cái cửa mà dữ liệu từ process đi qua rồi tới lớp mạng. Lớp transport tại host nhận sẽ không thực sự vận chuyển dữ liệu trực tiếp đến các process, thay vào đó nó chuyển đến các socket trung gian. Bởi vì trong một khoảng thời gian cho trước có thể có nhiều hơn một socket tại host nhận, mỗi socket sẽ có một số định danh duy nhất. Định dạng của các định danh (identifier) phụ thuộc vào socket đó là UDP hay TCP socket.
Nào hãy cùng suy ngẫm thử xem làm thế nào để các host nhận có thể định hướng trực tiếp các segments tới (incoming segments) đến socket thích hợp. Mỗi transport-layer segment có một tập hợp các trường trong segment để làm nhiệm vụ này. ở host nhận, transport layer sẽ thực hiện việc phân tích các segment để nhận dạng được các socket đích và chuyển segment tới socket đó. Công việc của việc vận chuyển dữ liệu trong transport layer segment đến đúng socket cần nhận được gọi là tách kênh. Công việc thu gôm dữ liệu tại host nguồn từ các nguồn socket khác nhau và đóng gói mỗi data chunk với thông tin header(được sử dụng khi tách kênh) để tạo các segments và chuyển tiếp các segments đên lớp mạng được gọi là ghép kênh. Lớp truyền tải sở dĩ tách kênh các segments đến các process thích hợp là do việc direct các dữ liệu trong segment đến (arriving segment's data ) đên các sockets thích hợp. Những host trung gian còn phải thu thập các dữ liệu ra từ các sockets, form các transport layer segment, và chuyển các segments đi xuống lớp mạng. Mặc dù được giới thiệu ghép kênh và tách kênh trong môi trường Internet, điều quan trọng là bạn nhận ra rằng chúng (ghép kênh và tách kênh) liên quan đến hầu hết giao thức nào là duy nhất đặt tại một layer (ví dụ như transport layer) được sử dụng bởi nhiều giao thức lớp trên.
Để hiểu về công việc tách kênh, ta nhắc lại về khái niệm tương tự : hộ gia đình. Mỗi đứa trẻ được nhận dạng bởi tên của cậu bé hay cô bé đó. Khi Bill nhận được một bó các mails từ mail carrier, anh ấy thực hiện công việc ''tách kênh'' thông qua việc quan xét xem ai được đánh địa chỉ trong bức thư và sau đó chuyển thư đến cho chị hay anh của anh ấy. Ann thực hiện việc ghép kênh khi cô ấy thu các mail từ chị và anh của cô ấy và gửi cho mail person.
Nào bây giờ chúng ta đã hiểu về việc ghép kênh và tách kênh tại lớp truyền tải, chúng ta hãy cùng phân tích làm thế nào chúng được hoàn thành trong host. Chúng ta biết răng transport-layer multiplexing yêu cầu các sockets có các định danh duy nhất (1). và mỗi segment có những trường đặc biệt để chỉ ra cho socket biết segments nào được vận chuyển. Các trường đặc biết đó là source port number field và destination port number field (đối với từng trường hợp TCP và UDP sẽ có những trường khác nhau). Mỗi chỉ số port là một số 16 bit chạy từ 0 đến 65535, các ports từ 0 - 1023 được gọi là các well-known port numbers và được hạn chế sử dụng, có nghĩa là các port này được sử dụng cho các ứng dụng well-known như là HTTP(80), FTP(21). Danh sách các ports nổi tiếng bạn có thể tham khảo trong RFC 1700 và được cập nhật trong RFC 3232. Khi chúng ta phát triển một ứng dụng chúng ta phải gán port ứng dụng.
Bây giờ rõ ràng bạn nên biết: Làm thế nào để transport layer có thể triển khai một ứng dụng tách kênh: Mỗi socket trong host có thể được gắn một port number, và khi segment đi tới một host, transport layer sẽ phân tích địa chỉ port đích trong segment và direct segment đó đên socket tương ứng. Dữ liệu của segment có thể băng qua socket để tìm tới process được dán vào socket đó. Như ta có thể thấy đó là cách UDP làm, riêng đối với TCP việc ghép tách kênh mang màu sắc tinh tế hơn.
Connectionless Multiplexing and Demultiplexing
Nhắc lại trong chương trước, một chương trình Java chạy trên host có thể tạo một UDP socket với dòng dưới đây:
DatagramSocket mySocket = new DatagramSocket();
Khi một UDP socket được tạo theo cách trên thì thì transport layer tự động gán một port number đến socket. Cụ thể hơn, transport layer sẽ gắn các port từ 1024 đến 65535 đến socket với một chú ý nhỏ rằng port được gán hiện không được sử dụng bởi socket nào khác trên host. Một sự thay thế, Java có thể tạo một UDP socket theo cách sau đây:
DatagramSocket mySocket = new DatagramSocket(19157);
Trong trường hợp này ứng dụng gán một port được chỉ định, 19157 đến UDP socket. Nếu người dụng viết code để triển khai một ứng dụng sử dụng "well-known protocol" khi đó người viết ứng dụng phải gán một giá well-known port number tương ứng. Về phía client các port sẽ tự động được gán trong khi tại phía server các port được chỉ định.
Với các port numbers được gán đến UDP sockets ta có thể mô tả chính xác định quá trinh UDP Multiplexing/ Demultiplexing. Giả sử process trong host A với UDP port number là 19157 muốn gửi một khối dữ liệu ứng dụng tới process với UDP port number là 46428 tại host B. Transport layer trong host A sẽ tạo một transport layer segment chứa dữ liệu của ứng dụng (application data), source port 19157 và destination port 46428 và 2 giá trị khác (sẽ được thảo luận sau). transport layer sau đó chuyển segment kết quả (the result segment) đến network layer. network layer sau đó đóng gói (encapsulate) segment trong IP datagram và tạo ra những điều kiện tốt nhất để vận chuyển segment tới host nhận. Nếu segment đến tại host nhận B, transport layer trong host nhận sẽ kiểm tra destination port number trong segment(46428) và vận chuyển segment đến socket của nó nhận dạng bởi port 46428. Chú ý rằng tại host B có thể chạy nhiều process với mỗi process sẽ có UDP socket cũng như port number tương ứng của riêng nó. Như đã biết khi các UDP segments đến từ mạng, host B sẽ direct (demultiplexing) mỗi segment đến nhưng socket tương xứng với nó thông qua việc kiểm tra destination port number.
Một điều quan trọng cần ghi chú đó là UDP socket hoàn toàn được định danh bởi một bộ destionation IP address và destination port number. Kết quả cho thấy, nếu 2 UDP segments có source IP address và/ hoặc source port number nhưng có chung destination IP address và destionation port number khi đó 2 segments sẽ được directed đến cùng một destionation process qua cùng một destination socket.
Chúng ta có thể tự hỏi ? Mục đích của source port number để làm gì ? Ví dụ trong A-to-B segment (segment gửi từ A đến B) source port number phục vụ như là một "return address"- Khi B muốn gửi segment ngược lại cho A, destination port trong B-to-A segment sẽ là source port number trong A-to-B segment (Địa chỉ đầy đủ trả về bao gồm địa chỉ IP nguồn của A và source port number). Trong UDPServer.java, server sử dụng một phương thức để extract source port number trong segment nó nhận được từ phía client, với source port number vừa extract được ở trên sẽ được sử dụng làm destination port number trong segment kế tiếp.
Connection-Oriented Multiplexing and Demultiplexing
Để hiểu về TCP demultiplexing , chúng ta cần quan sát kĩ TCP socket và TCP connection establishment (thiết lập kết nối TCP) . Một sự khác biệt tinh tế giữa TCP socket và UDP socket đó là TCP socket được định dạng bởi bộ bốn (four-tuple): (source IP address, source port number, destination IP address, destination port number). Do vậy, khi TCP segment đi từ network đến host, host sử dụng cả thẩy 4 giá trị để direct (demultiplex) segment đến socket thích hợp. Cụ thể hơn, trái ngược với UDP, 2 segments đến với địa IP source khác nhau hoặc source port numbers sẽ (với ngoại lệ là các TCP segment mang yêu cầu thiết lập kết nối ban đầu ( the original connection-establishment request) ). Được direct đến hai sockets khác nhau. Để có được cái nhìn cụ thể hơn. Hãy cùng suy ngẫm về TCP client-server programming
- TCP server application có một "welcoming socket " , những gì chờ đợi các connection-establishment requests từ phía TCP clients trên một port number, giả sử là 6789
- TCP client sẽ sinh ra một segment thiết lập kết nối (connection-establishment segment) với dòng sau
Socket clientSocket = new Socket ("serverHostName", 6789);
-Một request thiết lập kết nối đơn thuần chỉ là một TCP segment với destination port number 6789 và một bit đặc biệt trong TCP header phục vụ cho việc thiết lập kết nối. Segment còn bao gồm cả source port number, những gì được chọn bởi client. Dòng phía trên tạo một TCP socket cho client process, thông qua đó những data có thể được enter và rời khỏi client process.
- Khi hệ điều hành của host chạy server process nhận được một yêu cầu kết nối đến (incoming-connection request ) với destination port là 6789, nó xác định server process đang đợi để chấp nhận kết nối trên port 6789. Server process sau đó tạo ra một new socket:
Socket connectionSocket = welcomeSocket.accept()
- transport layer tại server ghi chú 4 giá trị trong connection-request segment: (1) source port number trong segment, (2) địa chỉ IP của host nguồn, (3) destination port number trong segment, (4) địa chỉ IP của chính nó. socket mới được tạo ra được nhận dạng bởi 4 giá trị trên. Tất cả các segments sau đó nếu match tất cả 4 giá trị trên sẽ được demultiplexed đên socket đó. Với TCP connection như trên, client và server có thể gửi dữ liệu cho nhau.
Server host có thể support nhiều TCP sockets đồng thời, với mỗi socket được gắn với một process, và mỗi socket được nhận dạng bởi four-tuple nêu trên. Khi một TCP segment đến host tất cả 4 trường (source IP address, source port, destination port number, destionation IP address) được sử dụng để direct (demultiplex) segment đến socket thích hợp.
Web Servers and TCP
Trước khi kết thúc bài thảo luận, thật hữu ích khi chúng ta nói một chút về Web servers và chúng sử dụng các port numbers như thế nào ?. Suy ngẫm, một host đang running một Web server, ví dụ như Apache web server, trên cổng 80. Khi clients (ví dụ như browsers) gửi các segments đến server, tất cả segments sẽ có destination port 80. Cụ thê hơn, cả các segments khởi động kết nối (initial connection-establishment segments) và các segments mang các HTTP request messages sẽ có destination port 80. Như đã mô tả trên, server sẽ phân biệt các clients khác nhau bằng cách sử dụng source IP address và source port numbers.
Web server sẽ sinh ra một new process cho mỗi kết nối, mỗi trong processes có connection socket riêng của nó, những gì HTTP requests đi tới và HTTP responses được gửi đi. Tuy nhiên không hẳn chỉ tồn tại một sự tương ứng one-to-one giữa connection sockets và processes. Các high performing Web servers ngày nay thường chỉ sử dụng một process và tạo một new thread với new connection socket cho mỗi client connection (thread có thể được nhìn nhận như một tiến trình con gọn nhẹ). Đối với server như trên, tại một thời gian cho trước có nhiều connection sockets (với các định danh (identifiers) khác nhau) gắn vào cùng một process.
Nếu client và server đang sử dụng sử dụng persistent HTTP(HTTP lâu dài), sau đó trong suốt quá trình của persistent connection nếu client và server trao đổi các HTTP messages thông qua cùng một server socket. Tuy nhiên, nếu client và server sử dụng non-persistent socket, một new TCP connection sẽ được tạo và đóng đối với mỗi request/response và hiển nhiên đi kèm nó là mỗi new socket connection được tạo cho mỗi request/response. Việc thường xuyên tạo và đóng các sockets có thể ảnh hưởng đến performance của các busy Web server (mặc dù cũng có những mẹo về hệ điều hành có thể giúp giảm thiểu điều này )
Hiểu về hàm repr() trong Python
cú pháp: repr(object)
Trả về một string chứa đại diện có thể in được (printable representation) của đối tượng. Kết quả trả về có cùng giá trị thu được qua những lần chuyển đổi (reverse quotes). Nó thỉnh thoảng hữu ích để có thể truy nhập đến operation này như là một hàm thông thường. Đối với nhiều dạng, hàm này có thể cố gắng lấy về một string giống như ta thực hiện hàm eval() cho string đó. Nếu không đại diện được đóng trong các angle brackets chứa tên của kiểu đối tượng cùng với những thông tin thêm về đối tượng đó như là: địa chỉ và tên. Một class có thể điều khiển những gì mà hàm này trả về cho mỗi instance của nó qua việc định nghĩa __repr()__ method.
Chúng ta cùng đi vào một vài ví dụ để hiểu rõ hơn về hàm này.
Tôi có
>>> x = 'foo' (1)
Thực hiện hàm repr():
>>> repr(x) (2)
Kết quả trả về:
"'foo'"
Tới đây có hai câu hỏi được đặt ra đó là:
1. Tại sao trong kết quả trả về lại xuất hiện dấu nháy kép ("" "")? Trong khi sử dụng hàm str() tôi không thấy?
2. Điều gì xảy ra khi ta sử dụng hàm eval() với kết quả vừa nhận, tức là eval("''foo")
Ta sẽ trả lời các câu hỏi trên sau khi tiếp cận một ví dụ sau đây:
Tôi có
>>> x = 'foo'
sau đó
>>> x
tôi thu được
'foo'
Ta thấy kết quả khác so với ví dụ phía trên, một cặp dấu nháy kép đúng không.
Quay trở lại ví dụ trên, tại dòng (1) ta thực hiện gán giá trị 'foo' cho biến x, khi ta gọi hàm repr(x) tại dòng (2) thì trình thông dịch sẽ thay thế x bởi 'foo ' và sau đó gọi hàm repr('foo')
>>> repr(x)
"'foo'"
>>> x.__repr__()
"'foo'"
repr thực sự gọi một magic method __repr__ của đối tượng x, có thể xem xét hàm repr() thực ra cũng chỉ là quá trình "function" hóa một phương thức trong đối tượng, thực sự thì trong hoàn cảnh này thì phương thức hay đối tượng cũng không thực sự khác nhau. Cả phương thức hay đối tượng đều trả về một string chứa đại diện cho giá trị 'foo' được gán cho biến x. Vì vậy nó trả lại một 'foo' nằm bên trong string ("""") và kết quả là "'foo'" như chúng ta thấy. Ý tưởng của repr là đưa ra một string chứa hàng loạt các biểu tượng (symbol) những gì chúng ta có thể gõ (type) trong trình thông dịch và có cùng giá trị với đầu vào của hàm repr.
>>> eval("'foo'")
'foo'
khi chúng ta gọi eval("'foo'") nó cũng giống như ta đánh 'foo' trong trinh thông dịch
>>> eval('foo')
Traceback (most recent call last):
File "<pyshell#83>", line 1, in <module>
eval('foo')
File "<string>", line 1, in <module>
NameError: name 'foo' is not defined
Nếu chúng ta gọi eval('foo') nó đồng nghĩa với việc chúng ta gõ foo trong trinh biên dịch và lỗi xảy ra bởi vì không giá trị foo nào có sắn hay nói cách khác là ta chưa tạo ra biến foo.
>>> str(x)
'foo'
>>> x.__str__()
'foo'
str chỉ là một biểu diễn string của đối tượng, với lẽ đó nó chỉ xuất ra kết quả là string
Một vài ví dụ
>>> x.__str__()
'foo'
>>> str(5)
'5'
>>> str('foo')
'foo'
Trả về một string chứa đại diện có thể in được (printable representation) của đối tượng. Kết quả trả về có cùng giá trị thu được qua những lần chuyển đổi (reverse quotes). Nó thỉnh thoảng hữu ích để có thể truy nhập đến operation này như là một hàm thông thường. Đối với nhiều dạng, hàm này có thể cố gắng lấy về một string giống như ta thực hiện hàm eval() cho string đó. Nếu không đại diện được đóng trong các angle brackets chứa tên của kiểu đối tượng cùng với những thông tin thêm về đối tượng đó như là: địa chỉ và tên. Một class có thể điều khiển những gì mà hàm này trả về cho mỗi instance của nó qua việc định nghĩa __repr()__ method.
Chúng ta cùng đi vào một vài ví dụ để hiểu rõ hơn về hàm này.
Tôi có
>>> x = 'foo' (1)
Thực hiện hàm repr():
>>> repr(x) (2)
Kết quả trả về:
"'foo'"
Tới đây có hai câu hỏi được đặt ra đó là:
1. Tại sao trong kết quả trả về lại xuất hiện dấu nháy kép ("" "")? Trong khi sử dụng hàm str() tôi không thấy?
2. Điều gì xảy ra khi ta sử dụng hàm eval() với kết quả vừa nhận, tức là eval("''foo")
Ta sẽ trả lời các câu hỏi trên sau khi tiếp cận một ví dụ sau đây:
Tôi có
>>> x = 'foo'
sau đó
>>> x
tôi thu được
'foo'
Ta thấy kết quả khác so với ví dụ phía trên, một cặp dấu nháy kép đúng không.
Quay trở lại ví dụ trên, tại dòng (1) ta thực hiện gán giá trị 'foo' cho biến x, khi ta gọi hàm repr(x) tại dòng (2) thì trình thông dịch sẽ thay thế x bởi 'foo ' và sau đó gọi hàm repr('foo')
>>> repr(x)
"'foo'"
>>> x.__repr__()
"'foo'"
repr thực sự gọi một magic method __repr__ của đối tượng x, có thể xem xét hàm repr() thực ra cũng chỉ là quá trình "function" hóa một phương thức trong đối tượng, thực sự thì trong hoàn cảnh này thì phương thức hay đối tượng cũng không thực sự khác nhau. Cả phương thức hay đối tượng đều trả về một string chứa đại diện cho giá trị 'foo' được gán cho biến x. Vì vậy nó trả lại một 'foo' nằm bên trong string ("""") và kết quả là "'foo'" như chúng ta thấy. Ý tưởng của repr là đưa ra một string chứa hàng loạt các biểu tượng (symbol) những gì chúng ta có thể gõ (type) trong trình thông dịch và có cùng giá trị với đầu vào của hàm repr.
>>> eval("'foo'")
'foo'
khi chúng ta gọi eval("'foo'") nó cũng giống như ta đánh 'foo' trong trinh thông dịch
>>> eval('foo')
Traceback (most recent call last):
File "<pyshell#83>", line 1, in <module>
eval('foo')
File "<string>", line 1, in <module>
NameError: name 'foo' is not defined
Nếu chúng ta gọi eval('foo') nó đồng nghĩa với việc chúng ta gõ foo trong trinh biên dịch và lỗi xảy ra bởi vì không giá trị foo nào có sắn hay nói cách khác là ta chưa tạo ra biến foo.
>>> str(x)
'foo'
>>> x.__str__()
'foo'
str chỉ là một biểu diễn string của đối tượng, với lẽ đó nó chỉ xuất ra kết quả là string
Một vài ví dụ
>>> x.__str__()
'foo'
>>> str(5)
'5'
>>> str('foo')
'foo'
Thứ Ba, 19 tháng 3, 2013
Access Networks
Ta xem xét các end systems và các ứng dụng đặt tại "edge of network". Nào bây giờ hay suy nghĩ về access networks. Các liên kết vậy lý kết nối một end system đến đên router đầu tiên (edge router) trên con đường đi từ end system này đến một system ở xa. Có rất nhiều công nghệ truy nhập được sử dụng, các mức độ cũng như các thành phần khác nhau của cấu trúc mạng điện thoại cố định truyền thống. Các hạ tầng đường dây điện thoại được cung cấp bởi các nhà cung cấp dịch vụ điện thoại địa phương, thường được gọi với cái tên telco. ví dụ cho các local telcos có thể kể đến như Verizon ở Mỹ hay France Telecom tại Pháp. Mỗi bộ phận cư trú (hộ gia đình hay chung cư) có một đường liên kết twisted-pair đấu nối trực tiếp đến telco switch gần nhất, những gì được đặt trong một tòa nhà gọi là Central Office (CO) theo thuật ngữ điện thoại. Một local telco sẽ có hàng trăm COs, và sẽ liên kết khách hàng của họ đến telco gần nhất.
1. Dial Up
Nhìn lại những năm 1990, hầu hết các khách hàng trong khu dân cư truy cập Internet thông qua kết nối sử dụng đường dây điện thoại thông thường sử dụng các dial up modem. Ngày nay còn rất nhiều quốc gia kém phát triển và các vùng nông thôn tại các quốc gia phát triển vẫn kết nối đến Internet thông qua dial up. Năm 2008 người ta ước lượng được rằng có 10% khách hàng tại Mỹ sử dụng kết nối dial up để đi vào internet.
thuật ngử "dial up" được sử dụng bởi vì khách hàng thực sự quay (dial) số điện thoại của ISP và tạo ra một cuộc gọi thông thường đến các ISP. PC được gắn với dial up modem, những gì cũng được gắn trên home's analog phone linet. analog phone line được tạo ra từ twisted-pair cooper wire và giống với đường dây điện thoại được sử dụng để tạo ra cuộc gọi. home modem thực hiện convert tín hiệu số từ PC sang tín hiệu analog để phù hợp cho việc vận chuyển trên analog phone line. Phía bên kia kết nối, một modem của ISP thực hiện convert tín hiệu analog thành tín hiệu số để phù hợp với đầu vào của các router.
Dial up Internet access có hai nhược điểm chính. Đầu tiên và quan trong nhất, nó thực sự chậm, dial up cung cấp tốc độ tối đa là 56Kbps, trung bình mất 8 phút để download một file MP3 dài 3 phút và mất đến một vài ngày để download một bộ phim với dung lượng 1Gbyte. thứ hai, dial up cạnh tranh đường dây điện thoại dùng để gọi điện, trong khi một thành viên trong gia đình sử dụng dial up modem để lướt web thì thành viên khác không thể gọi điện hay nhận điện thoại trên đường dây điện thoại được.
2. DSL
Ngày nay có hai kiểu phổ biến của việc truy cập Internet băng thông rộng đó là digital subscriber line (DSL) và cable. Trong xã hội phát triển hiện nay, có hơn 50% hộ gia đình có kết nối băng thông rộng tại Hàn Quốc, Iceland, Netherlands, Denmark và Switzerland dẫn đâu với 74% trong các hộ gia đình vào năm 2008. ở Mỹ, DSL và cable chia sẻ nhau thị phần trong kết nối băng thông rộng. Bên ngoài Mỹ và Canada, DSL chiếm ưu thế, tỷ dụ như khu vực Châu Âu trong nhiều nước DSL chiêm tới 90%.
Các thành phần cư trú (residence) có được Internet DSL access từ cùng một công ty cung cấp wired local telecom access (ví dụ như local telco). Do đó khi một DSL được sử dụng, một customer's telco cũng là một ISP của nó. mỗi customer's DSL modem sử dụng đường dây điện thoại đã tồn tại sắn (twisted-pair cooper wire) để trao đổi dữ liệu với Digital Subscribr Line Access Multiplexer (DSLAM), được đặt trong telco's CO đường dây điện thoại vận chuyển đồng thời cả dữ liệu và tín hiệu thoại, những gì được encoded tại các tần số khác nhau:
- A high speed downstream channel, trong khoảng từ 50khz đến 1MHz
- A medium speed upstream channel trong khoảng từ 4khz đến 50khz
- An ordinary two way telephone channel trong khoảng từ 0 đến 4khz
tại cùng một thời điểm. về phía khách hàng, đối với các tín hiệu đi đến nhà, bộ tách sẽ phân chia phần dữ liệu và phần tín hiệu thoại và chuyển tiếp phần dữ liệu đên DSL modem. về phía telco, DSLAM phân chia dữ liệu và tín hiệu điện thoại chuyển phần dữ liệu đi vào Internet. Có đến hàng trăm thậm chí là hàng ngàn hộ gia đinh kết nối đên một DSLAM đơn.
DSL có hai lợi thế chính so với dial up Internet access. Thứ nhất nó có thể chuyển và nhận dữ liệu ở tốc độ cao. Tiêu biểu như, DSL customer sẽ có tốc độ downstream (từ CO về đến dân cư) từ 1 đến 2 Mbps và trong khoảng từ 128Kbps đến 1 Mbps đối với upstream. bởi vì tỉ lệ downstream và upstream là khác nhau cho nên kiểu cập này là bất đối xứng. Đặc điểm lợi thế thứ hai là khách hàng có thể vừa sử dụng điện thoại vừa truy cập Internet, không giống như dial up , khách hàng không thể dial số điện thoại của ISP để có được kết nối Internet, thay vào đó chúng có một kết nối thường trực đến ISP's DSLAM (và hiển nhiên là đến Internet)
tỉ lệ transmission thực sự đối với downstream và upstream còn phụ thuộc vào khoảng cách từ nhà đên CO, sự đánh giá về twisted pair line và sự can thiệp của các tín hiệu điện. Các kĩ sư có thể thiết kế DSL với khoảng cách ngắn từ khách hàng đến các CO cho phép một tỉ lệ transmission cao hơn so với dial up. Để ''bật'' (boost) tỉ lệ dữ liệu. DSL phụ thuộc vào khả năng xử lý tín hiệu cấp cao và cơ chế chỉnh sửa lỗi những gì có thể làm cho độ trì hoãn packet cao. Tuy nhiên, nếu khách hàng không nằm trong phạm vi 5 đến 10 miles của CO thì việc xử lý tín hiệu DSL là không có hiệu quả và khách hàng phải cân nhắc đến sử dụng một kiểu kết nối Internet khác.
Có một vài công nghệ DSL tốc độ cao khác nhau thâm nhập vào thị trường và hữu dụng cho ngày hôm nay. Cho ví dụ very high speed DSL (VDSL) được sử dụng nhiều tại Nam Hàn và Nhật bản, cung cấp một tỉ lệ ấn tượng 12 đên 55 Mbps cho downstream và 1.6 đến 20Mbps cho upstream.
3. Cable
Nhiều residences (người sử dụng) ở Bắc Mỹ và một số nơi khác nhận hàng trăm kênh truyền hình thông qua coaxial cable networks. Trong hệ thống truyền hình cable truyền thống, cable head end phát các kênh truyền hình thông qua mạng lưới phân bố coaxial cable và các ampliers đến với các residences.
trong khi DSL và dial up sử dụng hạ tầng đường dây điện thoại thì cable Internet access sử dụng các đường cable truyền hình tồn tại sẵn trên hệ tầng truyền hình. các residence đạt được truy cập Internet từ chính các công ty cung cấp truyền hình cable....
1. Dial Up
Nhìn lại những năm 1990, hầu hết các khách hàng trong khu dân cư truy cập Internet thông qua kết nối sử dụng đường dây điện thoại thông thường sử dụng các dial up modem. Ngày nay còn rất nhiều quốc gia kém phát triển và các vùng nông thôn tại các quốc gia phát triển vẫn kết nối đến Internet thông qua dial up. Năm 2008 người ta ước lượng được rằng có 10% khách hàng tại Mỹ sử dụng kết nối dial up để đi vào internet.
thuật ngử "dial up" được sử dụng bởi vì khách hàng thực sự quay (dial) số điện thoại của ISP và tạo ra một cuộc gọi thông thường đến các ISP. PC được gắn với dial up modem, những gì cũng được gắn trên home's analog phone linet. analog phone line được tạo ra từ twisted-pair cooper wire và giống với đường dây điện thoại được sử dụng để tạo ra cuộc gọi. home modem thực hiện convert tín hiệu số từ PC sang tín hiệu analog để phù hợp cho việc vận chuyển trên analog phone line. Phía bên kia kết nối, một modem của ISP thực hiện convert tín hiệu analog thành tín hiệu số để phù hợp với đầu vào của các router.
Dial up Internet access có hai nhược điểm chính. Đầu tiên và quan trong nhất, nó thực sự chậm, dial up cung cấp tốc độ tối đa là 56Kbps, trung bình mất 8 phút để download một file MP3 dài 3 phút và mất đến một vài ngày để download một bộ phim với dung lượng 1Gbyte. thứ hai, dial up cạnh tranh đường dây điện thoại dùng để gọi điện, trong khi một thành viên trong gia đình sử dụng dial up modem để lướt web thì thành viên khác không thể gọi điện hay nhận điện thoại trên đường dây điện thoại được.
2. DSL
Ngày nay có hai kiểu phổ biến của việc truy cập Internet băng thông rộng đó là digital subscriber line (DSL) và cable. Trong xã hội phát triển hiện nay, có hơn 50% hộ gia đình có kết nối băng thông rộng tại Hàn Quốc, Iceland, Netherlands, Denmark và Switzerland dẫn đâu với 74% trong các hộ gia đình vào năm 2008. ở Mỹ, DSL và cable chia sẻ nhau thị phần trong kết nối băng thông rộng. Bên ngoài Mỹ và Canada, DSL chiếm ưu thế, tỷ dụ như khu vực Châu Âu trong nhiều nước DSL chiêm tới 90%.
Các thành phần cư trú (residence) có được Internet DSL access từ cùng một công ty cung cấp wired local telecom access (ví dụ như local telco). Do đó khi một DSL được sử dụng, một customer's telco cũng là một ISP của nó. mỗi customer's DSL modem sử dụng đường dây điện thoại đã tồn tại sắn (twisted-pair cooper wire) để trao đổi dữ liệu với Digital Subscribr Line Access Multiplexer (DSLAM), được đặt trong telco's CO đường dây điện thoại vận chuyển đồng thời cả dữ liệu và tín hiệu thoại, những gì được encoded tại các tần số khác nhau:
- A high speed downstream channel, trong khoảng từ 50khz đến 1MHz
- A medium speed upstream channel trong khoảng từ 4khz đến 50khz
- An ordinary two way telephone channel trong khoảng từ 0 đến 4khz
tại cùng một thời điểm. về phía khách hàng, đối với các tín hiệu đi đến nhà, bộ tách sẽ phân chia phần dữ liệu và phần tín hiệu thoại và chuyển tiếp phần dữ liệu đên DSL modem. về phía telco, DSLAM phân chia dữ liệu và tín hiệu điện thoại chuyển phần dữ liệu đi vào Internet. Có đến hàng trăm thậm chí là hàng ngàn hộ gia đinh kết nối đên một DSLAM đơn.
DSL có hai lợi thế chính so với dial up Internet access. Thứ nhất nó có thể chuyển và nhận dữ liệu ở tốc độ cao. Tiêu biểu như, DSL customer sẽ có tốc độ downstream (từ CO về đến dân cư) từ 1 đến 2 Mbps và trong khoảng từ 128Kbps đến 1 Mbps đối với upstream. bởi vì tỉ lệ downstream và upstream là khác nhau cho nên kiểu cập này là bất đối xứng. Đặc điểm lợi thế thứ hai là khách hàng có thể vừa sử dụng điện thoại vừa truy cập Internet, không giống như dial up , khách hàng không thể dial số điện thoại của ISP để có được kết nối Internet, thay vào đó chúng có một kết nối thường trực đến ISP's DSLAM (và hiển nhiên là đến Internet)
tỉ lệ transmission thực sự đối với downstream và upstream còn phụ thuộc vào khoảng cách từ nhà đên CO, sự đánh giá về twisted pair line và sự can thiệp của các tín hiệu điện. Các kĩ sư có thể thiết kế DSL với khoảng cách ngắn từ khách hàng đến các CO cho phép một tỉ lệ transmission cao hơn so với dial up. Để ''bật'' (boost) tỉ lệ dữ liệu. DSL phụ thuộc vào khả năng xử lý tín hiệu cấp cao và cơ chế chỉnh sửa lỗi những gì có thể làm cho độ trì hoãn packet cao. Tuy nhiên, nếu khách hàng không nằm trong phạm vi 5 đến 10 miles của CO thì việc xử lý tín hiệu DSL là không có hiệu quả và khách hàng phải cân nhắc đến sử dụng một kiểu kết nối Internet khác.
Có một vài công nghệ DSL tốc độ cao khác nhau thâm nhập vào thị trường và hữu dụng cho ngày hôm nay. Cho ví dụ very high speed DSL (VDSL) được sử dụng nhiều tại Nam Hàn và Nhật bản, cung cấp một tỉ lệ ấn tượng 12 đên 55 Mbps cho downstream và 1.6 đến 20Mbps cho upstream.
3. Cable
Nhiều residences (người sử dụng) ở Bắc Mỹ và một số nơi khác nhận hàng trăm kênh truyền hình thông qua coaxial cable networks. Trong hệ thống truyền hình cable truyền thống, cable head end phát các kênh truyền hình thông qua mạng lưới phân bố coaxial cable và các ampliers đến với các residences.
trong khi DSL và dial up sử dụng hạ tầng đường dây điện thoại thì cable Internet access sử dụng các đường cable truyền hình tồn tại sẵn trên hệ tầng truyền hình. các residence đạt được truy cập Internet từ chính các công ty cung cấp truyền hình cable....
Client và Server programs
Trong bối cảnh của networking software, có một định nghĩa khác về client và server, một client program có nghĩa là một chương trình chạy trên một end system thực hiện việc truy vấn và nhận dịch vụ từ server program chạy trên một end system khác. Các ứng dụng phổ biến như Web, email, remote-login hay FTP đều hoạt động dựa theo mô hình client-server. Bởi vì client program chạy trên một end system trong khi một server program chạy trên một end system khác nên ta gọi các ứng dụng client-server trên Internet là các distributed applications. Tới đây có lẽ phải nhắc lại, thế distributed applications là gì ? Các ứng dụng được gọi là distributed applications bởi vì chúng khi hoạt động yêu cầu nhiều end systems trao đổi dữ liệu với nhau. Một điều quan trọng hơn đó là các distributed applications này chỉ chạy được trên các end systems, chúng không chạy được trên các packet switches trong các network core. Thế network core là gì ? network core cũng chỉ là tập hợp của các packet switches và các communication links. Các client program và server program thực hiện việc tương tác thông qua sự trao đổi các thông điệp với nhau trên Internet. Trừu tượng hóa, ta có thể coi các routers, links và các nuts and bolts của mạng Internet phục vụ như một chiếc hộp đen có nhiệm vụ vận chuyển các messages giữa các thành phần ứng dụng, các thành phần giao tiếp của ứng dụng Internet.
Không hoàn toàn tất cả các ứng dụng Internet hiện nay là dựa trên sự tương tác giữa client program và server program. Sự tăng trưởng của nhiều ứng dụng Peer to Peer (P2P), những gì mà end systems tương tác và chạy các chương trình thực hiện cả nhiệm của client lẫn server. Cho ví dụ, trong P2P file sharing applications (ví dụ như BitTorent và eMule), chương trình trong máy user hoạt động như là một client khi nó yêu cầu một file từ peer khác, và nó hoạt động như server khi nó gửi file đến peer khác. Trong ứng dụng điện thoại Internet, có hai thành phần giao tiếp đóng vai trò như các peers, phiên giao tiếp là đối xứng, với cả hai thành phần gửi và nhận dữ liệu.
Không hoàn toàn tất cả các ứng dụng Internet hiện nay là dựa trên sự tương tác giữa client program và server program. Sự tăng trưởng của nhiều ứng dụng Peer to Peer (P2P), những gì mà end systems tương tác và chạy các chương trình thực hiện cả nhiệm của client lẫn server. Cho ví dụ, trong P2P file sharing applications (ví dụ như BitTorent và eMule), chương trình trong máy user hoạt động như là một client khi nó yêu cầu một file từ peer khác, và nó hoạt động như server khi nó gửi file đến peer khác. Trong ứng dụng điện thoại Internet, có hai thành phần giao tiếp đóng vai trò như các peers, phiên giao tiếp là đối xứng, với cả hai thành phần gửi và nhận dữ liệu.
Thứ Tư, 5 tháng 12, 2012
Vài Script cho chống DOS
http://software-security.sans.org/blog/2010/01/06/dos-attack-after-action-report-shell-scripts
Đăng ký:
Bài đăng (Atom)