Transcription
Chào bạn, tôi là Carrie Anne, và chào mừng bạn đến với CrashCourse Khoa học Máy tính! Như chúng ta đã nói ở tập trước, máy tính của bạn được kết nối với một mạng lưới phân tán lớn, gọi là Internet. Tôi biết điều này vì bạn đang xem một video trên YouTube, được truyền phát qua chính Internet đó. Nó được sắp xếp như một mạng lưới các thiết bị được kết nối với nhau, ngày càng mở rộng. Để máy tính của bạn nhận được video này, kết nối đầu tiên là với mạng cục bộ của bạn, hay LAN, có thể là mọi thiết bị trong nhà bạn được kết nối với bộ định tuyến wifi của bạn. Sau đó, nó kết nối với Mạng diện rộng, hay WAN, có khả năng là một bộ định tuyến do Nhà cung cấp Dịch vụ Internet của bạn, hay ISP – các công ty như Comcast, AT&T hoặc Verizon – vận hành. Ban đầu, đây sẽ là một bộ định tuyến khu vực, giống như một bộ định tuyến cho khu phố của bạn, và sau đó bộ định tuyến đó kết nối với một WAN lớn hơn nữa, có thể là một bộ định tuyến cho toàn bộ thành phố hoặc thị trấn của bạn. Có thể có thêm một vài bước trung gian, nhưng cuối cùng bạn sẽ kết nối với xương sống của Internet được tạo thành từ các bộ định tuyến khổng lồ với các kết nối băng thông siêu cao chạy giữa chúng. Để yêu cầu tệp video này từ YouTube, một gói tin đã phải đi lên đến xương sống, di chuyển dọc theo đó một chút, và sau đó đi xuống máy chủ YouTube có tệp đó. Có thể là bốn bước lên, hai bước ngang qua xương sống, và bốn bước xuống, tổng cộng mười bước. Nếu bạn đang chạy Windows, MacOS hoặc Linux, bạn có thể xem đường đi dữ liệu đến các địa điểm khác nhau trên Internet bằng cách sử dụng chương trình traceroute trên máy tính của mình. Hướng dẫn trong Doobly Doo. Đối với chúng tôi tại Studio Chad & Stacey Emigholz ở Indianapolis, đường đi đến máy chủ DFTBA ở California đi qua 11 điểm dừng. Chúng tôi bắt đầu tại 192.168.0.1 – đó là địa chỉ IP cho máy tính của tôi trên mạng LAN của chúng tôi. Sau đó là bộ định tuyến wifi ở đây tại studio, sau đó là một loạt các bộ định tuyến khu vực, sau đó chúng tôi kết nối với xương sống, và sau đó chúng tôi bắt đầu đi xuống máy tính lưu trữ “DFTBA dot com”, có địa chỉ IP 104.24.109.186. Nhưng làm thế nào một gói tin thực sự đến đó? Điều gì xảy ra nếu một gói tin bị mất trên đường đi? Nếu tôi gõ “DFTBA dot com” vào trình duyệt web của mình, làm thế nào nó biết địa chỉ của máy chủ? Đó là những chủ đề của chúng ta hôm nay!
INTRO
Như chúng ta đã thảo luận ở tập trước, Internet là một mạng lưới phân tán khổng lồ gửi dữ liệu dưới dạng các gói tin nhỏ. Nếu dữ liệu của bạn đủ lớn, như một tệp đính kèm email, nó có thể bị chia thành nhiều gói tin. Ví dụ, luồng video này đang được gửi đến máy tính của bạn ngay bây giờ dưới dạng một loạt các gói tin, chứ không phải một tệp khổng lồ duy nhất. Các gói tin Internet phải tuân theo một tiêu chuẩn gọi là Giao thức Internet, hay IP. Nó giống như gửi thư vật lý qua hệ thống bưu điện – mỗi lá thư cần một địa chỉ duy nhất và dễ đọc được ghi trên đó, và có giới hạn về kích thước và trọng lượng của các gói hàng. Vi phạm điều này, và thư của bạn sẽ không đến được. Các gói tin IP rất giống nhau. Tuy nhiên, IP là một giao thức rất cấp thấp – không có nhiều hơn một địa chỉ đích trong tiêu đề của gói tin, là siêu dữ liệu được lưu trữ trước tải trọng dữ liệu. Điều này có nghĩa là một gói tin có thể xuất hiện tại một máy tính, nhưng máy tính có thể không biết ứng dụng nào sẽ nhận dữ liệu; Skype hay Call of Duty. Vì lý do này, các giao thức tiên tiến hơn đã được phát triển nằm trên IP. Một trong những giao thức đơn giản và phổ biến nhất là Giao thức Datagram Người dùng, hay UDP. UDP có tiêu đề riêng, nằm bên trong tải trọng dữ liệu. Bên trong tiêu đề UDP có một số thông tin bổ sung hữu ích. Một trong số đó là số cổng. Mỗi chương trình muốn truy cập Internet sẽ yêu cầu Hệ điều hành của máy tính chủ của nó được cấp một cổng duy nhất. Ví dụ, Skype có thể yêu cầu số cổng 3478. Khi một gói tin đến máy tính, Hệ điều hành sẽ xem bên trong tiêu đề UDP và đọc số cổng. Sau đó, nếu nó thấy, ví dụ, 3478, nó sẽ chuyển gói tin cho Skype. Vì vậy, để xem lại, IP đưa gói tin đến đúng máy tính, nhưng UDP đưa gói tin đến đúng chương trình đang chạy trên máy tính đó. Tiêu đề UDP cũng bao gồm một thứ gọi là checksum, cho phép dữ liệu được xác minh tính chính xác. Như tên gọi cho thấy, nó thực hiện điều này bằng cách kiểm tra tổng của dữ liệu. Đây là một phiên bản đơn giản hóa về cách thức hoạt động. Hãy tưởng tượng dữ liệu thô trong gói tin UDP của chúng ta là 89 111 33 32 58 và 41. Trước khi gói tin được gửi, máy tính truyền sẽ tính toán checksum bằng cách cộng tất cả dữ liệu lại với nhau: 89 cộng 111 cộng 33, v.v. Trong ví dụ của chúng ta, tổng này là 364. Trong UDP, giá trị checksum được lưu trữ trong 16 bit. Nếu tổng vượt quá giá trị tối đa có thể, các bit ở trên cùng sẽ tràn, và chỉ các bit ở dưới cùng được sử dụng. Bây giờ, khi máy tính nhận gói tin này, nó lặp lại quy trình, cộng tất cả dữ liệu lại. 89 cộng 111 cộng 33, v.v. Nếu tổng đó giống với checksum được gửi trong tiêu đề, mọi thứ đều ổn. Nhưng, nếu các số không khớp, bạn biết rằng dữ liệu đã bị hỏng tại một thời điểm nào đó trong quá trình truyền, có thể do dao động điện hoặc cáp bị lỗi. Thật không may, UDP không cung cấp bất kỳ cơ chế nào để sửa dữ liệu, hoặc yêu cầu một bản sao mới – các chương trình nhận được thông báo về sự hỏng hóc, nhưng thường chỉ loại bỏ gói tin. Ngoài ra, UDP không cung cấp bất kỳ cơ chế nào để biết liệu các gói tin có được gửi thành công hay không – máy tính gửi sẽ gửi gói tin UDP đi, nhưng không có xác nhận nào cho thấy nó đã đến đích thành công. Cả hai thuộc tính này đều có vẻ khá thảm khốc, nhưng một số ứng dụng chấp nhận được điều này, vì UDP cũng rất đơn giản và nhanh. Ví dụ, Skype, sử dụng UDP cho trò chuyện video, có thể xử lý các gói tin bị hỏng hoặc bị mất. Đó là lý do tại sao đôi khi nếu bạn có kết nối Internet kém, Skype sẽ bị trục trặc – chỉ một số gói tin UDP mới đến được máy tính của bạn. Skype làm hết sức mình với dữ liệu mà nó nhận được một cách chính xác. Nhưng cách tiếp cận này không hoạt động đối với nhiều loại truyền dữ liệu khác. Ví dụ, nó không thực sự hoạt động nếu bạn gửi một email, và nó xuất hiện với phần giữa bị thiếu. Toàn bộ tin nhắn thực sự cần phải đến nơi một cách chính xác! Khi nó “chắc chắn phải đến nơi”, các chương trình sử dụng Giao thức Truyền dẫn, hay TCP, giống như UDP, nằm bên trong tải trọng dữ liệu của các gói tin IP. Vì lý do này, mọi người gọi sự kết hợp các giao thức này là TCP/IP. Giống như UDP, tiêu đề TCP chứa một cổng đích và checksum. Nhưng, nó cũng chứa các tính năng phức tạp hơn, và chúng ta sẽ tập trung vào những tính năng chính. Đầu tiên, các gói tin TCP được đánh số tuần tự. Vì vậy, gói tin 15 được theo sau bởi gói tin 16, được theo sau bởi 17, và cứ thế... cho hàng triệu gói tin có thể được gửi trong phiên đó. Các số thứ tự này cho phép máy tính nhận sắp xếp các gói tin theo đúng thứ tự, ngay cả khi chúng đến vào các thời điểm khác nhau trên mạng. Vì vậy, nếu một email đến bị xáo trộn, việc triển khai TCP trong hệ điều hành máy tính của bạn sẽ ghép nối tất cả lại một cách chính xác. Thứ hai, TCP yêu cầu rằng một khi máy tính đã nhận được một gói tin một cách chính xác – và dữ liệu vượt qua checksum – thì nó sẽ gửi lại một xác nhận, hay “ACK” như những người sành điệu nói, cho máy tính gửi. Biết gói tin đã đến thành công, người gửi giờ có thể truyền gói tin tiếp theo. Nhưng lần này, giả sử, nó đợi, và không nhận được gói tin xác nhận trở lại. Phải có gì đó sai. Nếu đủ thời gian trôi qua, người gửi sẽ tiếp tục và chỉ truyền lại cùng một gói tin. Cần lưu ý rằng gói tin gốc có thể đã thực sự đến nơi, nhưng xác nhận chỉ bị trì hoãn rất nhiều. Hoặc có lẽ chính xác nhận đã bị mất. Dù bằng cách nào, điều đó không quan trọng, bởi vì người nhận có các số thứ tự đó, và nếu một gói tin trùng lặp đến, nó có thể bị loại bỏ. Ngoài ra, TCP không giới hạn ở cuộc trò chuyện qua lại – nó có thể gửi nhiều gói tin, và có nhiều ACK đang chờ xử lý, điều này làm tăng băng thông đáng kể, vì bạn không lãng phí thời gian chờ đợi các gói tin xác nhận quay trở lại. Thú vị thay, tỷ lệ thành công của ACK, và cả thời gian khứ hồi giữa việc gửi và xác nhận, có thể được sử dụng để suy ra tình trạng tắc nghẽn mạng. TCP sử dụng thông tin này để điều chỉnh mức độ tích cực gửi các gói tin – một cơ chế kiểm soát tắc nghẽn. Vì vậy, về cơ bản, TCP có thể xử lý việc phân phối gói tin không theo thứ tự, các gói tin bị bỏ rơi – bao gồm cả truyền lại – và thậm chí điều chỉnh tốc độ truyền theo băng thông có sẵn. Khá tuyệt vời! Bạn có thể tự hỏi tại sao ai đó lại sử dụng UDP khi TCP có tất cả các tính năng tiện lợi này. Nhược điểm lớn nhất là tất cả các gói tin xác nhận đó – nó nhân đôi số lượng tin nhắn trên mạng, và tuy nhiên, bạn không truyền thêm bất kỳ dữ liệu nào. Chi phí đó, bao gồm cả sự chậm trễ liên quan, đôi khi không đáng để có được sự mạnh mẽ được cải thiện, đặc biệt đối với các ứng dụng quan trọng về thời gian, như Trò chơi Bắn súng Góc nhìn Thứ nhất Nhiều người chơi. Và nếu bạn bị lag-fragged thì bạn chắc chắn sẽ đồng ý! Khi máy tính của bạn muốn thiết lập kết nối với một trang web, bạn cần hai thứ – một địa chỉ IP và một cổng. Giống như cổng 80, tại 172.217.7.238. Ví dụ này là địa chỉ IP và cổng cho máy chủ web Google. Trên thực tế, bạn có thể nhập cái này vào thanh địa chỉ của trình duyệt, như thế này, và bạn sẽ truy cập trang chủ Google. Điều này đưa bạn đến đúng đích, nhưng việc ghi nhớ chuỗi số dài đó sẽ rất khó chịu. Dễ nhớ hơn nhiều: google.com. Vì vậy, Internet có một dịch vụ đặc biệt ánh xạ các tên miền này với địa chỉ. Nó giống như danh bạ điện thoại của Internet. Và nó được gọi là Hệ thống Tên miền, hay DNS viết tắt. Bạn có thể đoán cách nó hoạt động. Khi bạn gõ một cái gì đó như “youtube.com” vào trình duyệt web của mình, nó sẽ đi và yêu cầu một máy chủ DNS – thường là một máy chủ do ISP của bạn cung cấp – để tra cứu địa chỉ. DNS tham khảo cơ sở dữ liệu khổng lồ của nó và trả lời bằng địa chỉ... nếu có. Trên thực tế, nếu bạn thử gõ lung tung bàn phím, thêm “.com”, và sau đó nhấn enter trong trình duyệt của mình, bạn có thể sẽ thấy một lỗi báo DNS thất bại. Đó là bởi vì trang web đó không tồn tại, vì vậy DNS không thể cung cấp cho trình duyệt của bạn một địa chỉ. Nhưng, nếu DNS trả về một địa chỉ hợp lệ, như nó nên có cho “youtube.com”, thì trình duyệt của bạn sẽ gửi một yêu cầu qua TCP cho dữ liệu của trang web. Có hơn 300 triệu tên miền đã đăng ký, vì vậy để làm cho việc Tra cứu DNS này dễ quản lý hơn một chút, nó không được lưu trữ dưới dạng một danh sách khổng lồ, mà dưới dạng một cấu trúc dữ liệu cây. Cái gọi là Tên miền Cấp cao nhất, hay TLD, nằm ở trên cùng. Đây là những danh mục lớn như .com và .gov. Sau đó, có các tên miền cấp thấp hơn nằm bên dưới đó, gọi là tên miền cấp hai; Ví dụ dưới .com bao gồm google.com và dftba.com. Sau đó, có các tên miền cấp thấp hơn nữa, gọi là tên miền phụ, như images.google.com, store.dftba.com. Và cây này thực sự KHỔNG LỒ! Như tôi đã nói, hơn 300 triệu tên miền, và đó chỉ là tên miền cấp hai, không phải tất cả các tên miền phụ. Vì lý do này, dữ liệu này được phân tán trên nhiều máy chủ DNS, là các cơ quan có thẩm quyền cho các phần khác nhau của cây. Được rồi, tôi biết bạn đã chờ đợi nó... Chúng ta đã đạt đến một cấp độ trừu tượng mới! Trong hai tập vừa qua, chúng ta đã đi từ tín hiệu điện trên dây, hoặc tín hiệu vô tuyến truyền qua không khí trong trường hợp mạng không dây. Cái này được gọi là Lớp Vật lý. Địa chỉ MAC, phát hiện va chạm, quay số theo cấp số nhân và các giao thức cấp thấp tương tự điều phối truy cập vào lớp vật lý là một phần của Lớp Liên kết Dữ liệu. Phía trên lớp này là Lớp Mạng, nơi tất cả các công nghệ chuyển mạch và định tuyến mà chúng ta đã thảo luận hoạt động. Và hôm nay, chúng ta chủ yếu đề cập đến Lớp Vận chuyển, các giao thức như UDP và TCP, chịu trách nhiệm truyền dữ liệu điểm-tới-điểm giữa các máy tính, và cả những thứ như phát hiện và phục hồi lỗi khi có thể. Chúng ta cũng đã lướt qua Lớp Phiên – nơi các giao thức như TCP và UDP được sử dụng để mở kết nối, trao đổi thông tin qua lại, và sau đó đóng kết nối khi hoàn thành – cái được gọi là một phiên. Đây chính xác là những gì xảy ra khi bạn, ví dụ, thực hiện Tra cứu DNS, hoặc yêu cầu một trang web. Đây là năm lớp dưới cùng của mô hình Open System Interconnection (OSI), một khuôn khổ khái niệm để phân chia tất cả các quy trình mạng khác nhau này. Mỗi cấp độ có những điều khác nhau để lo lắng và giải quyết, và sẽ không thể xây dựng một triển khai mạng khổng lồ duy nhất. Như chúng ta đã nói trong suốt loạt bài, trừu tượng hóa cho phép các nhà khoa học và kỹ sư máy tính cải thiện tất cả các cấp độ khác nhau của ngăn xếp này đồng thời, mà không bị choáng ngợp bởi toàn bộ sự phức tạp. Và đáng kinh ngạc, chúng ta vẫn chưa xong… Mô hình OSI có thêm hai lớp nữa, Lớp Trình bày và Lớp Ứng dụng, bao gồm những thứ như trình duyệt web, Skype, giải mã HTML, truyền phát phim và hơn thế nữa. Mà chúng ta sẽ nói vào tuần tới. Hẹn gặp lại bạn.