Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Vấn đề thiết kế - gửi dữ liệu nhỏ phân đoạn qua Giao thức Kiểm soát Truyền Winsock

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch thuật của Microsoft và có thể được Cộng đồng Microsoft chỉnh sửa lại thông qua công nghệ CTF thay vì một biên dịch viên chuyên nghiệp. Microsoft cung cấp các bài viết được cả biên dịch viên và phần mềm dịch thuật thực hiện và cộng đồng chỉnh sửa lại để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng nhiều ngôn ngữ Tuy nhiên, bài viết do máy dịch hoặc thậm chí cộng đồng chỉnh sửa sau không phải lúc nào cũng hoàn hảo. Các bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này: 214397
Tóm tắt
Khi bạn muốn gửi gói nhỏ dữ liệu qua Giao thức Kiểm soát Truyền, thiết kế ứng dụng Winsock của bạn là đặc biệt quan trọng. Thiết kế không đưa vào tài khoản tương tác thừa nhận bị trì hoãn, Nagle thuật toán và Winsock đệm đáng kể có thể ảnh hưởng đến hiệu năng. Bài viết này thảo luận về các sự cố này, sử dụng một số trường hợp nghiên cứu, và có một loạt các khuyến nghị để gửi gói nhỏ dữ liệu hiệu quả từ ứng dụng Winsock.
Thông tin thêm

Nền

Khi một ngăn xếp Microsoft Giao thức Kiểm soát Truyền nhận được một gói dữ liệu, thời gian chậm trễ 200-ms bị. Khi một ACK cuối cùng gửi, thời gian chậm trễ được đặt lại và sẽ Bắt đầu một 200-ms trễ khi nhận được gói dữ liệu tiếp theo.Để tăng hiệu quả Internet và các ứng dụng nội bộ, chồng Microsoft Giao thức Kiểm soát Truyền sử dụng các tiêu chuẩn để quyết định khi gửi một ACK gói dữ liệu đã nhận:
  • Nếu gói dữ liệu thứ hai được nhận trước khi hết hạn thời gian chậm trễ, ACK được gửi.
  • Nếu không có dữ liệu được gửi trong cùng một hướng như ACK trước khi nhận được hai gói dữ liệu và thời gian chậm trễ hết hạn, ACK được piggybacked với các phân đoạn dữ liệu và gửi ngay lập tức.
  • Khi hết hạn thời gian chậm trễ, ACK được gửi.
Để tránh việc gói dữ liệu nhỏ congest mạng, ngăn xếp Microsoft Giao thức Kiểm soát Truyền cho phép thuật toán Nagle theo mặc định, coalesces một bộ đệm dữ liệu nhỏ nhiều gửi cuộc gọi và sự chậm trễ gửi nó cho đến khi một ACK cho các gói dữ liệu trước gửi nhận được từ máy chủ từ xa. Sau đây là hai trường hợp ngoại lệ Nagle thuật toán:
  • Nếu ngăn xếp có lại bộ đệm dữ liệu lớn hơn đơn vị truyền tối đa (MTU), một gói kích thước đầy đủ sẽ được gửi ngay lập tức mà không cần chờ ACK từ máy chủ từ xa. Trên một mạng Ethernet, MTU cho TCP/IP là 1460 byte.
  • Tuỳ chọn ổ cắm TCP_NODELAY được áp dụng để vô hiệu hoá các thuật toán Nagle để gói nhỏ dữ liệu được gửi đến máy chủ từ xa không chậm trễ.
Tối ưu hoá hiệu suất ở lớp ứng dụng, Winsock bản bộ đệm dữ liệu từ ứng dụng gửi cuộc gọi đến một bộ đệm lõi Winsock. Sau đó, ngăn xếp sử dụng riêng chẩn đoán (chẳng hạn như thuật toán Nagle) để xác định thời gian thực sự lên gói dây. Bạn có thể thay đổi số lượng lõi Winsock đệm cho ổ cắm bằng cách sử dụng tuỳ chọn SO_SNDBUF (đó là 8K theo mặc định). Nếu cần, Winsock có đệm đáng kể hơn SO_SNDBUF đệm kích thước. Trong hầu hết các trường hợp, hoàn tất gửi trong ứng dụng chỉ cho biết bộ đệm dữ liệu trong ứng dụng gửi cuộc gọi được sao chép vào bộ đệm lõi Winsock và chỉ ra rằng dữ liệu đã đạt môi trường mạng. Ngoại lệ duy nhất là khi bạn vô hiệu hoá bộ đệm Winsock bằng cách đặt SO_SNDBUF thành 0.

Winsock sử dụng các quy tắc để chỉ hoàn tất gửi một ứng dụng (tuỳ thuộc vào cách gửi được kích hoạt, thông báo hoàn thành có thể là chức năng từ một cuộc gọi chặn, tín hiệu một sự kiện hoặc gọi hàm thông báo, và như vậy cứ):
  • Nếu ổ cắm vẫn còn trong SO_SNDBUF hạn ngạch, Winsock sao chép dữ liệu từ ứng dụng gửi và chỉ hoàn tất gửi ứng dụng.
  • Nếu ổ cắm vượt quá hạn ngạch SO_SNDBUF và chỉ có một việc đã gửi vẫn còn trong bộ đệm lõi ngăn xếp, Winsock sao chép dữ liệu từ ứng dụng gửi và chỉ hoàn tất gửi ứng dụng.
  • Nếu ổ cắm vượt quá hạn ngạch SO_SNDBUF và có nhiều hơn một đệm đã gửi trong bộ đệm lõi ngăn xếp, Winsock sao chép dữ liệu từ ứng dụng gửi. Winsock không chỉ hoàn tất gửi ứng dụng cho đến khi hoàn tất các đủ gửi đặt khe cắm lại trong SO_SNDBUF hạn ngạch hoặc chỉ gửi nổi bật điều kiện.

Nghiên cứu 1

Tổng quan:

Khách hàng Winsock Giao thức Kiểm soát Truyền cần gửi 10000 bản ghi máy chủ Winsock Giao thức Kiểm soát Truyền để lưu trữ trong bộ máy cơ sở dữ liệu. Kích thước của các hồ sơ khác nhau từ 20 byte 100 byte dài. Để đơn giản hóa logic ứng dụng, thiết kế là như sau:
  • Khách hàng hiện chặn gửi chỉ. Máy chủ hiện chặn nhận chỉ.
  • Khe cắm máy tính khách đặt SO_SNDBUF thành 0 để mỗi hồ sơ đi một phân đoạn dữ liệu duy nhất.
  • Nhận cuộc gọi máy chủ trong một vòng lặp. Bộ đệm gửi nhận là 200 byte để mỗi hồ sơ có thể nhận được một nhận cuộc gọi.

Hiệu suất:

Trong quá trình kiểm tra, các nhà phát triển tìm thấy máy tính khách chỉ có thể gửi các bản ghi năm giây cho máy chủ. Ghi 10000 tổng, tối đa ở 976K byte dữ liệu (10000 * 100 / 1024), có nhiều hơn một giờ để gửi tới máy chủ.

Phân tích:

Bởi vì khách hàng không đặt tùy chọn TCP_NODELAY, thuật toán Nagle buộc chồng Giao thức Kiểm soát Truyền chờ một ACK trước khi nó có thể gửi một gói trên dây. Tuy nhiên, khách hàng đã vô hiệu hoá bộ đệm Winsock bằng cách đặt tùy chọn SO_SNDBUF 0. Vì vậy, các 10000 gửi cuộc gọi có thể gửi và ACK'ed cá nhân. Mỗi ACK là 200-ms chậm do sau xảy ra trên máy chủ chồng TCP:
  • Khi máy chủ được một gói, 200-ms trễ giờ bị.
  • Máy chủ không cần gì, do đó, không piggybacked ACK.
  • Khách hàng sẽ gửi một gói nếu gói trước đó được ghi nhận.
  • Thời gian chậm trễ trên máy chủ hết hạn và ACK được gửi lại.

Làm thế nào để cải thiện:

Có hai vấn đề với thiết kế này. Trước tiên, có là số giờ chậm trễ. Khách hàng phải có thể gửi gói hai máy chủ trong 200-bà do khách hàng sử dụng các thuật toán Nagle theo mặc định, nó sẽ chỉ sử dụng bộ đệm Winsock mặc định và không đặt SO_SNDBUF thành 0. Khi chồng Giao thức Kiểm soát Truyền có lại bộ đệm lớn hơn đơn vị truyền tối đa (MTU), một gói kích thước đầy đủ được gửi ngay lập tức mà không cần chờ ACK từ máy chủ từ xa.

Thứ hai, thiết kế này gọi một gửi cho mỗi hồ sơ như kích thước nhỏ. Gửi nhỏ có kích thước này không hiệu quả. Trong trường hợp này, các nhà phát triển có thể pad mỗi hồ sơ đến 100 byte và gửi hồ sơ 80 lần từ một máy tính khách gửi cuộc gọi. Để biết bao nhiêu hồ sơ sẽ được gửi trong tổng số máy chủ, khách hàng có thể Bắt đầu giao tiếp với một tiêu đề có kích thước sửa chữa có số liệu theo.

Nghiên cứu 2

Tổng quan:

Ứng dụng khách Winsock Giao thức Kiểm soát Truyền mở hai kết nối với ứng dụng máy chủ Winsock Giao thức Kiểm soát Truyền nhà cung cấp bản ghi dịch vụ giá cổ phiếu. Kết nối đầu tiên được sử dụng như một kênh lệnh cho biểu tượng cổ phiếu vào máy chủ. Kết nối thứ hai được sử dụng như một kênh dữ liệu nhận báo giá chứng khoán. Sau khi hai kết nối đã được thiết lập, máy tính khách gửi biểu tượng cổ phiếu vào máy chủ thông qua kênh lệnh và chờ báo giá chứng khoán trở lại qua kênh dữ liệu. Nó gửi yêu cầu mã chứng khoán sau cho máy chủ chỉ sau khi nhận được báo giá chứng khoán đầu tiên. máy tính khách và máy chủ không đặt tuỳ chọn SO_SNDBUF và TCP_NODELAY.

Hiệu suất:

Trong quá trình kiểm tra, nhà phát triển tìm thấy các khách hàng có thể chỉ có dấu kiểm ngoặc kép năm giây.

Phân tích:

Thiết kế này chỉ cho phép yêu cầu báo giá chứng khoán nổi bật một lần. Biểu tượng cổ phiếu đầu tiên được gửi đến máy chủ thông qua kênh lệnh (kết nối) và trả lời được gửi lại từ máy chủ cho khách hàng qua kênh dữ liệu (kết nối). Sau đó, khách hàng ngay lập tức gửi yêu cầu chứng khoán biểu tượng thứ hai và gửi trả lại ngay lập tức khi bộ đệm yêu cầu gửi cuộc gọi được sao chép vào bộ đệm lõi Winsock. Tuy nhiên, ngăn xếp Giao thức Kiểm soát Truyền khách hàng không thể gửi yêu cầu từ lõi đệm ngay lập tức vì đầu tiên gửi qua kênh lệnh không nhận được. 200-ms hoãn giờ ở kênh lệnh máy chủ hết hạn, ACK cho yêu cầu biểu tượng đầu tiên trở lại cho khách hàng. Sau đó, yêu cầu báo thứ hai được gửi thành công vào máy chủ sau khi bị trì hoãn cho 200-cô trích dẫn cho các biểu tượng cổ phiếu thứ hai Quay lại ngay lập tức thông qua kênh dữ liệu do thời gian này, thời gian chậm trễ tại kênh dữ liệu của khách hàng đã hết hạn. Một ACK cho phản hồi báo trước đó được nhận bởi máy chủ. (Hãy nhớ rằng khách hàng có thể gửi yêu cầu báo giá chứng khoán thứ hai 200-ms, do đó cho thời gian cho thời gian chậm trễ trên máy tính khách hết hạn và gửi một ACK cho máy chủ.) Do đó, khách hàng được phản hồi báo thứ hai và có thể phát hành một yêu cầu báo giá, có thể cùng một chu kỳ.

Làm thế nào để cải thiện:

Thiết kế hai kết nối (kênh) là không cần thiết ở đây. Nếu bạn sử dụng một kết nối cho yêu cầu báo giá chứng khoán và phản hồi, ACK cho yêu cầu trích dẫn có thể được piggybacked trên trả lời trích dẫn và Quay lại ngay lập tức. Để tiếp tục cải thiện hiệu năng, khách hàng có thể "Bits" yêu cầu báo giá chứng khoán nhiều vào một gửi cuộc gọi đến máy chủ và máy chủ có thể cũng "Bits" nhiều báo trả lời vào một cuộc gọi gửi cho khách hàng. Nếu thiết kế hai kênh unidirectional là cần thiết cho một số lý do, cả hai bên phải đặt tùy chọn TCP_NODELAY gói nhỏ có thể được gửi ngay lập tức mà không cần phải chờ một ACK cho gói trước đó.

Khuyến nghị:

Trong khi những nghiên cứu trường hợp hai được tạo ra, họ giúp minh hoạ một số kịch bản trường hợp xấu nhất. Khi bạn thiết kế ứng dụng liên quan đến dữ liệu nhỏ mở rộng phân đoạn gửi và recvs, bạn nên xem xét các hướng dẫn sau:
  • Nếu dữ liệu phân đoạn không gian quan trọng, ứng dụng sẽ hợp nhất chúng vào một khối dữ liệu lớn để vượt qua cuộc gọi gửi. Do bộ đệm gửi có thể được sao chép vào bộ đệm lõi Winsock, bộ đệm không nên quá lớn. Một chút ít hơn 8K là thường có hiệu quả. Như lõi Winsock một khối lớn hơn so với MTU, nó sẽ gửi nhiều gói kích thước đầy đủ và một gói cuối cùng với bất kỳ còn lại. Phía gửi, ngoại trừ các gói mới, sẽ không được trúng 200-ms trễ giờ. Gói cuối cùng, nếu nó là một gói số lẻ, phải vẫn tuân thủ thuật toán trễ thừa nhận. Nếu ngăn xếp cuối gửi bị chặn một lớn hơn MTU, nó vẫn có thể bỏ qua các thuật toán Nagle.
  • Nếu có thể tránh khe cắm kết nối với dòng unidirectional dữ liệu. Truyền thông qua khe cắm unidirectional là thêm dễ bị ảnh hưởng bởi Nagle và bị trì hoãn thuật toán thừa nhận. Nếu giao tiếp theo yêu cầu và dòng đáp ứng, bạn nên sử dụng một khe cắm duy nhất để thực hiện việc gửi và recvs để ACK có thể được piggybacked trên phản hồi.
  • Nếu tất cả các phân đoạn nhỏ dữ liệu đã được gửi ngay lập tức, đặt tùy chọn TCP_NODELAY cuối gửi.
  • Nếu bạn muốn đảm bảo một gói được gửi trên dây khi hoàn tất gửi được chỉ định bởi Winsock, bạn không nên đặt SO_SNDBUF không. Thực tế, bộ đệm 8K mặc định đã được xác định nhờ hoạt động tốt cho hầu hết các trường hợp và bạn sẽ không thay đổi trừ khi bạn đã thử cài đặt chuyên biệt bộ đệm Winsock mới cung cấp cho bạn các hoạt động tốt hơn mặc định. Ngoài ra, thiết lập SO_SNDBUF 0 chủ yếu là lợi ích cho các ứng dụng lớn truyền dữ liệu. Thậm chí sau đó tối đa hiệu quả bạn nên sử dụng cùng với hai buffering (nhiều nổi bật gửi tại bất kỳ thời gian nhất định) và chồng chéo I/O.
  • Nếu cung cấp dữ liệu không phải đảm bảo, sử dụng UDP.
Tham khảo
Để biết thêm thông tin về thừa nhận trì hoãn và thuật toán Nagle, vui lòng xem sau:

Braden, R. [1989], RFC 1122, yêu cầu cho Internet Internet lưu trữ - lớp liên lạc, tác vụ bắt buộc.

Warning: This article has been translated automatically

Thuộc tính

ID Bài viết: 214397 - Xem lại Lần cuối: 03/14/2015 10:02:00 - Bản sửa đổi: 3.0

  • kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock kbmt KB214397 KbMtvi
Phản hồi