BÁO CÁO ĐỒ ÁN 4 ĐỀ TÀI: TÌM HIỂU VÀ XÂY DỰNG CHƯƠNG TRÌNH HTTP SERVER . Th.S Nguyễn Văn Bình

ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG VIỆT - HÀN KHOA KHOA HỌC MÁY TÍNH - - BÁO CÁO ĐỜ ÁN ĐỀ TÀI: TÌM HIỂU VÀ XÂY DỰNG CHƯƠNG TRÌNH HTTP SERVER Sinh viên thực : Lớp GVHD : : Ngô Mỹ Hanh Nguyễn Thị Nguyệt Minh 18IT1 + 18IT2 Th.S Nguyễn Văn Bình Đà Nẵng, tháng 11 năm 2020 ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG VIỆT - HÀN KHOA KHOA HỌC MÁY TÍNH - - BÁO CÁO ĐỜ ÁN ĐỀ TÀI: TÌM HIỂU VÀ XÂY DỰNG CHƯƠNG TRÌNH HTTP SERVER Sinh viên thực : Lớp GVHD : : Ngô Mỹ Hanh Nguyễn Thị Nguyệt Minh 18IT1 + 18IT2 Th.S Nguyễn Văn Bình Đà Nẵng, tháng 11 năm 2020 MỤC LỤC LỜI CẢM ƠN LỜI NÓI ĐẦU CHƯƠNG CƠ SỞ LÝ THUYẾT 1.1 Tổng quan về lập trình mạng 1.1.1 Khái niệm 1.1.2 Ngôn ngữ lập trinh mạng .9 1.1.3 Thư viện hỗ trơ .9 1.1.4 Mô hình phân tầng .10 1.1.5 Giao thức mạng 15 1.2 Tìm hiểu về web server 16 1.2.1 Web server gì? 16 1.2.2 Những phần quan trọng web server 16 1.2.3 Chức web server 17 1.2.4 Web server hoạt động nào? 17 1.2.5 Những lưu ý sử dụng web server 18 1.3 Giới thiệu về giao thức HTTP .19 1.3.1 HTTP gì 19 1.3.2 Các đặt trưng HTTP 19 1.3.3 Cấu trúc 19 1.3.4 Ưu nhươc điểm giao thức HTTP 20 1.4 Tổng quan về ngôn ngữ Java 20 1.4.1 Ngôn ngữ Java gì? 20 1.4.2 Đặc điểm ngôn ngữ Java 21 1.4.3 Tại nên sử dụng Java? 21 1.4.4 Java đươc ứng dụng đâu? 22 CHƯƠNG PHÂN TÍCH HỆ THỐNG 23 2.1 HTTP Application Protocol dạng stateless 23 2.2 Các phương thức giao tiếp HTTP 23 2.2.1 GET 24 2.2.2 POST 24 2.2.3 PUT 24 2.2.4 DELETE 25 2.2.5 HEAD 25 2.2.6 CONNECT 25 2.2.7 OPTIONS 26 2.2.8 TRACE 26 2.3 Các trường header HTTP .26 2.3.1 General Header 27 2.3.2 Request-Header (Các trường Header yêu cầu Client) 30 2.3.3 Response-Header (Các trường Phản hồi từ Server) 34 2.3.4.Entity Headers .36 2.4 HTTP status codes 37 2.4.1 HTTP status codes gì? 37 2.4.2 Các loại HTTP status code 38 CHƯƠNG DEMO CHƯƠNG TRÌNH 41 3.1 Chạy demo chương trình: .41 CHƯƠNG IV ĐÁNH GIÁ KẾT QUẢ ĐẠT ĐƯỢC VÀ HƯỚNG PHÁT TRIỂN ĐỀ TÀI 44 4.1 Đánh giá kết đạt đươc: 44 4.2 Hướng phát triển đề tài: 45 KẾT LUẬN 46 TÀI LIỆU THAM KHẢO 47 MỤC LỤC BẢNG Bảng 1: Bảng mô tả ngắn gọn hành động phương thức HTTP 24 Bảng 2: Bảng dẫn yêu cầu nhớ ẩn sử dụng Client 27 Bảng 3: Bảng dẫn phản hồi nhớ ẩn sử dụng Server phản hồi 28 Bảng 4: Bảng miêu tả tính trường Set-Cookie 35 MỤC LỤC HÌNH ẢNH Hình 1: Mơ hình OSI .10 Hình 2: Mơ hình TCP/IP 13 Hình Những phần quan trọng web server 17 Hình Hoạt động web server 17 Hình Cấu trúc HTTP 20 Hình Giao diện mở cởn 41 Hình Giao diện tắt server .41 Hình 3 Giao diện thay đổi port 42 Hình Giao diện thông bao quản lý client 42 Hình 5Giao diện chạy HTTP 43 NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… …………………………………………………………………………………… ………………………………………………………… Chữ ký giảng viên hướng dẫn ……………………………… LỜI CẢM ƠN Trên thực tế khơng có sự thành cơng mà khơng gắn liền với những sự hỗ trơ, giúp đỡ dù hay nhiều, dù trực tiếp hay gián tiếp người khác Trong suốt quãng thời gian từ bắt đầu học tập tại giảng đường trường Đại học công nghệ thông tin truyền thông Việt Hàn - Đại học Đà Nẵng, nhận đươc nhiều sự quan tâm, giúp đỡ thầy cô các bạn Với lịng biết ơn sâu sắc nhất, nhóm chúng tơi xin gửi lời cảm ơn chân thành tới tồn thể các thầy cô giáo khoa Công nghệ thông tin truyền thông Đại học Việt Hàn, những người dạy dỗ truyền đạt vốn kiến thức vô quý báu mình cho suốt quãng thời gian học tại Những tình cảm kiến thức mà thầy cô gửi trao cho hành trang cho để bước những đoạn đường tương lai Nhóm chúng tơi xin gửi lời cảm ơn sâu sắc tới Thầy Nguyễn Văn Bình, người tận tình hỗ trơ dẫn dắt nhóm chúng tơi suốt quá trình thực đồ án để có đươc kết cách tốt Một lần nhóm chúng tơi xin chân thành cảm ơn! LỜI NĨI ĐẦU Ngành cơng nghệ thông tin ngành khoa học đà phát triển mạnh ứng dụng rộng rãi nhiều lĩnh vực Cùng với xu hướng phát triển các phương tiện truyền thông báo, radio… thì việc sử dụng internet ngày phổ biến Truy cập internet có đươc kho thơng tin khởng lồ phục vụ nhu cầu, mục đích cái nhấp chuột Nhận thức đươc nhu cầu tìm hiểu thơng tin, giải trí xã hội, sự đời hàng loạt website cho các mục đích thương mại, giải trí tin tức… Để đáp ứng với việc cập nhật thông tin hàng ngày, tình hình xã hội, trị, thời sự, sức khỏe… thì website thứ tất yếu Do nhóm chúng tơi vận dụng những hiểu biết nhóm mình về Apache, PHP, MySQL, để xây dựng web server website Sau thời gian học tập tại trường, đươc sự bảo hướng dẫn nhiệt tình thầy cô giáo trường Đại học Công nghệ Thông tin Truyền thông Việt - Hàn, kết thúc khoá học tích luỹ đươc vốn kiến thức định Đươc sự đồng ý nhà trường thầy Phan Trọng Thanh đươc giao đề tài : “Tìm hiểu và xây dựng một chương trình HTTP Server” Đồ án môn học gồm chương: Chương 1: Cơ sở lý thuyết Chương 2: Phân tích hệ thống Chương 3: Demo chương trình Chương 4: Đánh giá kết đạt đươc hướng phát triển CHƯƠNG CƠ SỞ LÝ THUYẾT 1.1 Tổng quan về lập trình mạng 1.1.1 Khái niệm Lập trình mạng các kỹ thuật lập trình nhằm xây dựng những ứng dụng, phần mềm khai thác hiệu tài nguyên mạng máy tính Mạng máy tính ngày phát triển, ứng dụng mạng đem lại không thể phủ nhận Ngày nói đến phát triển các ứng dụng phần mềm, đa số người ta muốn nói đến chương trình có khả làm việc mơi trường mạng tích hơp nói chung mạng máy tính nói riêng Từ các chương trình kế toán doanh nghiệp, quản lý, trò chơi, điều khiển đều các chương trình ứng dụng mạng Vấn đề lập trình mạng liên quan đế nhiều lĩnh vực kiến thức khác Từ kiến thức sử dụng ngơn ngữ lập trình, phân tích thiết kế hệ thống, kiến thức hệ thống mạng, mô hình xây dựng chương trình ứng dụng mạng, kiến thức về sở dữ liệu kiến thức truyền thông, các kiến thức các lĩnh vực liên quan khác mạng điện thoại di động, PSTN, hệ thống GPS, các mạng BlueTooth, WUSB, mạng sensor Nhưng có thể nói vấn đề lập trình mạng có vấn đề cốt lõi tích hơp lập trình ứng dụng mạng đươc thể hình Hay nói cách khác, vấn đề lập trình mạng có thể đươc định nghĩa với công thức sau: LTM = KTM + MH + NN LTM: Lập trình mạng KTM: Kiến thức mạng truyền thơng (mạng máy tính, PSTN, ) MH: Mơ hình lập trình mạng NN: Ngôn ngữ lập trình mạng 1.1.2 Ngôn ngữ lập trinh mạng Hầu hết các ngôn ngữ lập trình mạng đều có thể sử dụng để lập trình mạng, nhiên việc lập trình mạng phù thuộc vào các thư viện mơi trường lập trình có hỗ trơ hay khơng Có thể liệt kê các ngơn ngữ lập trình có thể sử dụng để lập trình mạng sau: C/C++: Ngôn ngữ lập trình mạnh phổ biến, dùng để viết loại ứng dụng có ứng dụng mạng Java: Ngơn ngữ lập trình khá thông dụng hổ trơ nhiều môi trường, tỏng có thể viết ứng dụng chạy điện thoại di động C#: Ngôn ngữ lập trình mạnh dễ sử dụng, hổ trơ họ hệ điều hành Windows Microsoft Python, Perl, Php…: Các ngôn ngữ thông dịch, dử dụng để viết nhanh các tiện ích nhỏ cách nhanh chống, có thể sử dụng để viết ứng dụng mạng 1.1.3 Thư viện hỗ trơ Việc lập trình mạng phụ thuộc nhiều vào các thư viện hỗ trơ đến từ hệ thống Tùy thuộc vào nền tảng phát triển ứng dụng mà có thể sử dụng các thư viện khác Có thể liệt kê với thư viện hỗ trơ lập trình mạng sau: - Winsock: Thư viện liên kết động Microsoft, đươc phân phối hệ điều hành Windows Winsock cung cấp khá nhiều API để phát triển ứng dụng mạng Winsock có thể sử dụng ngôn ngữ lập trình nào, đôi C/C++ Winsock đem lại hiệu cao nhất, tương đối khó sử dụng - Thư viện System.Net NET framework: Thư viện cung cấp nhiều API dễ sử dụng để xây dựng ứng dụng mạng Để sử dụng thư viện này, người ta thường dùng C# Việc phát triển ứng dụng mạng nhờ thư viện khá dễ dàng - Thư viện MFC Socket: Thư viện phát triển Visual Studio C++ Đây thư viện không dễ sử dụng - Các thư viện Java Runtime, PHP,… 1.1.4 Mô hình phân tầng a Mơ hình OSI: Hình 1: Mơ hình OSI Mơ hình OSi có lớp đươc thiết kế theo các nguyên tắc sau: - Một lớp đươc tạo tương đương với khái niệm trừu tương - Một lớp thực chức hồn chỉnh - Chức lớp phải đươc chọn theo xu hướng phù hơp với các giao thức đươc chuẩn hóa - Biên các lớp phải đươc thiết kế cho tối thiểu hóa đươc lương thơng tin truyền qua các giao diện Vai trò chức tầng OSI: Trong mô hình OSI, khả kiểm soát đươc luân chuyển từ tầng tới tầng khác, quá trình tầng 7, sau đươc chủn đến tầng dưới thơng qua các kênh tới các station sau lưu hierarchy Mô hình OSI tầng tiếp nhận nhiệm vụ liên mạng, tiến hành chia thành các tầng tương ứng đươc xếp chồng lên Một dấu (*) kết nối với bất cứ đối tương nào, sự truyền tải tiếp tục đối tương tồn tại.Ví dụ: If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: * Nếu khơng có thể đối tương kết nối, (*) đươc cung cấp không đối tương tại tồn tại, Server không đươc trình bày method đươc yêu cầu, phải trả lại phản hồi 412 (điều kiện trước thất bại) Trường If-Modified-Since: Trường đươc sử dụng với method để làm cho có điều kiện Nếu URL đươc u cầu khơng đươc chỉnh sửa từ thời gian đươc xác định trường này, đối tương không đươc trả lại từ Server; thay vào đó, phản hồi 304 (khơng đươc chỉnh sửa) đươc trả lại mà khơng có bất cứ phần thân thông báo Cú pháp chung: If-Modified-Since : HTTP-date Ví dụ: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT Nếu khơng có thẻ đối tương kết nối với, "*" đươc cung cấp không đối tương tại tồn tại,, Server không đươc trình bày method đươc yêu cầu, phải trả lại phản hồi 412 (điều kiện trước thất bại) Trường If-None-Match: Trường đươc sử dụng với method để làm cho có điều kiện Trường yêu cầu Server trình bày method đươc yêu cầu số giá trị cho thẻ kết nối với các thẻ đối tương đươc cung cấp biểu diễn Etag Cú pháp chung: If-None-Match : entity-tag Một dấu * kết nối với đối tương nào, sự truyền tải tiếp tục đối tương khơng tồn tại.Ví dụ: If-None-Match: "xyzzy" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: * Trường If-Range: Trường If-Range có thể đươc sử dụng với GET có điều kiện để yêu cầu phần đối tương mà bị thất lạc, khơng đươc thay đởi, tồn đối tương đươc thay đởi Cú pháp chung: If-Range : entity-tag | HTTP-date Hoặc thẻ đối tương dữ liệu có thể đươc sử dụng để xác minh đối tương nội nhận Ví dụ: If-Range: Sat, 29 Oct 1994 19:43:31 GMT Tại đây, tài liệu không đươc chỉnh sửa từ ngày cho, Server trả lại dãy byte đươc cung cấp trường Range, khơng thì trả lại tất các tài liệu mới Trường If-Unmodified-Since: Trường đươc sử dụng với method để làm cho có điều kiện Cú pháp chung: If-Unmodified-Since : HTTP-date Nếu nguồn đươc yêu cầu không đươc chỉnh sửa từ thời gian đươc xác định trường này, Server sẻ thực hoạt động đươc yêu cầu IfUnmodified-Since không biểu diễn Ví dụ: If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT Nếu yêu cầu có kết bất cứ gì khác trạng thái 2xx 4xx, thì trường If-Unmodified-Since nên đươc bỏ qua Trường Max-Forwards: Trường cung cấp kỹ thuật với các phương thức TRACE OPTIONS để giới hạn số các trạm ủy quyền gateway mà có thể chuyển tiếp yêu cầu tới Server Cú pháp chung: Max-Forwards : n Giá trị Max-Forward số nguyên hệ thập phân số lần cịn lại thơng báo u cầu có thể đươc chuyển tiếp Điều hữu ích cho debug với phương thức TRACE, tránh đươc các vịng lặp vơ hạn Ví dụ: Max-Forwards : Trường có thể bị bỏ qua với tất các phương thức đươc định nghĩa định cấu hình HTTP Trường Proxy-Authorization: Trường cho phép Client xác nhận (hoặc người sử dụng nó) tới trạm ủy quyền mà yêu cầu sự ủy nhiệm Cú pháp chung: Proxy-Authorization : credentials Giá trị trường Proxy-Authorization bao gồm các sự ủy nhiệm chứa thông tin ủy nhiệm user agent cho trạm ủy nhiệm và/hoặc phạm vi nguồn đươc yêu cầu Trường Range: Trường Range xác định dãy nội nội dung đươc yêu cầu từ tài liệu Cú pháp chung: Range: bytes-unit=first-byte-pos "-" [last-byte-pos] Giá trị First-byte-pos byte-range-spec chung cấp byte-offset byte dãy Giá trị last-byte-pos cung cấp byte-offset byte cuối dãy; là, các vị trí byte đươc xác định Bạn có thể xác định đơn vị byte các byte Byte offset bắt đầu tại 0.Ví dụ: The first 500 bytes Range: bytes=0-499- The second 500 bytes Range: bytes=500-999- The final 500 bytes Range: bytes=-500- The first and last bytes only Range: bytes=0-0,-1 Nhiều dãy có thể đươc liệt kê, phân biệt dấu phảy Nếu chữ số dãy byte phân biệt dấu phảy bị bỏ quên, dãy đươc giả sử tính toán từ phần cuối tài liệu Nếu chữ số thứ hai bị bỏ quên, dãy byte thứ n tới phần cuối tài liệu Trường Referer Trường cho phép Client xác định địa URI nguồn mà từ URL đươc yêu cầu Cú pháp chung: Referer : absoluteURI | relativeURI Ví dụ: Referer: http://www.tutorialspoint.org /http/index.jsp Nếu giá trị trường URI quan hệ, nên đươc phiên dịch liên quan tới Request-URI Trường TE: Trường sự mở rộng mà transfer-coding muốn chấp nhận phản hồi có khơng muốn chấp nhận các trường trailer transfer-coding đươc đóng khối Cú pháp chung: TE : t-codings Sự diện từ khóa "trailers" Client muốn chấp nhận các trường trailer transfer-coding đươc đóng khối đươc xác định theo cách: TE: deflate TE: TE: trailers, deflate;q=0.5 Nếu giá trị trường TE trống không trường TE diện, thì có transfer-coding đươc đóng khối (chunked) Một thông báo với không transfercoding ln có thể chấp nhận Trường User-Agent: Trường User-Agent chứa thông tin về tác nhân người sử dụng tạo yêu cầu Sau cú pháp chung: User-Agent : product | comment Ví dụ: User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) 2.3.3 Response-Header (Các trường Phản hồi từ Server) Trường Accept-Ranges: Trường cho phép Server sự chấp nhận về các dãy yêu cầu cho nguồn Cú pháp chung: Accept-Ranges : range-unit | none Ví dụ, Server mà chấp nhận các yêu cầu về dãy byte có thể gửi: AcceptRanges: bytes Server mà khơng chấp nhận loại dãy yêu cầu cho nguồn có thể gửi: Accept-Ranges: none Điều khuyên Client không cố gắng để chiếm đươc dãy yêu cầu Trường Age: Trường Age chuyển tính toán về số lương thời gian từ phản hồi đươc tạo tại Server ban đầu người gửi Cú pháp chung: Age : delta-seconds Giá trị Age các số nguyên thập phân khơng phủ định, biểu diễn thời gian giây.Ví dụ: Age: 1030 Một HTTP/1.1 Server mà bao gồm nhớ ẩn phải bao gồm trường Age phản hồi đươc tạo từ nhớ ẩn riêng Trường Etag: Trường Etag cung cấp giá trị tại thẻ đối tương cho biến thể đươc yêu cầu Cú pháp chung: ETag : entity-tag Ví dụ: ETag: "xyzzy" ETag: W/"xyzzy" ETag: "" Trường Location: Trường Location đươc sử dụng để điều hướng lại người nhận tới vị trí khác ngồi Reqest-URI Cú pháp chung: Location : absoluteURI Ví dụ: Location: http://www.tutorialspoint.org /http/index.jsp Trường Content-Location khác Location mà Content-Location xác nhận vị trí ban đầu đối tương đươc bao gồm yêu cầu Trường Proxy-Authenticate: Trường phải đươc bao gồm phần phản hồi 407 Cú pháp chung: Proxy-Authenticate : challenge Trường Retry-After: Trường có thể đươc sử dụng với phản hồi 503 (Service Unavailable dịch vụ khơng có sẵn) để dịch vụ đươc mong đơi để khơng có sẵn vịng tới Client yêu cầu Cú pháp chung: Retry-After : HTTP-date | deltaseconds Các ví dụ: Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120 Trong ví dụ sau, sự trì hoãn phút Trường Server: Trường chứa thông tin về phần mềm đươc sử dụng Server ban đầu để kiểm soát yêu cầu Cú pháp chung: Server : product | comment Ví dụ: Server: Apache/2.2.14 (Win32) Nếu phản hồi đươc chuyển tiếp qua trạm ủy quyền, ứng dụng ủy quyền không đươc chỉnh sửa trường Server Trường Set-Cookie Trường chứa cặp tên/giá trị thông tin để giữ lại cho URL Cú pháp chung: Set-Cookie: NAME=VALUE; OPTIONS Trường phản hồi Set-Cookie bao gồm Set-Cookie dấu hiệu, đươc theo sau danh sách đươc phân biệt dấu phảy nhiều cookie Ở các giá trị có thể mà bạn có thể xác định các tính năng: STT Các tính miêu tả Comment=comment Tính có thể đươc sử dụng để xác định bất cứ lời bình liên kết với cookie Domain=domain Thuộc tính Domain xác định miền mà với cookie có hiệu lực Expires=Date-time Ngày mà cookie hết hạn Nếu trống, cookie hết hạn khách sử dụng rời khỏi trình duyệt Path=path Thuộc tính path xác định thiết lập phụ các URL mà cookie áp dụng Secure Nó dẫn user agent để trả lại cookie dưới dạng kết nối an toàn Bảng 4: Bảng miêu tả tính trường Set-Cookie Ví dụ cookie đơn giản đươc tạo Server: Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT Trường Vary: Trường Vary xác định đối tương có nhiều nguồn vì có thể theo nhiều cách để tới danh sách yêu cầu đươc xác định Cú pháp chung: Vary : field-name Bạn có thể xác định nhiều Header phân biệt dấu phảy giá trị dấu * mà không xác định các tham số (không giới hạn tới các Header yêu cầu).Ví dụ: Vary: Accept-Language, Accept-Encoding Trường WWW-Authenticate: Trường phải đươc bao gồm các thông báo phản hồi 401 (không đươc ủy quyền) Giá trị trường bao gồm challenge (hiệu lệnh) mà dẫn giản đồ ủy quyền các tham số có thể áp dụng tới URI yêu cầu Cú pháp chung: WWWAuthenticate : challenge Giá trị tường có thể chứa nhiều challenge, nhiều trường WWW-Authenticate đươc cung cấp, các nội dung challenge có thể chứa danh sách đươc phân biệt dấu phảy các tham số ủy quyền.Ví dụ: WWW-Authenticate: BASIC realm="Admin" 2.3.4.Entity Headers Trường Allow: Trường liệt kê thiết lập các method đươc hỗ trơ nguồn đươc xác nhận Request-URI Cú pháp chung: Allow : Method Bạn có thể xác định nhiều phương thức đươc phân biệt dấu phảy.Ví dụ: Allow: GET, HEAD, PUT Trường không ngăn cản Client từ việc cố gắng thử các method khác Trường Content-Encoding: Trường đươc sử dụng chỉnh sửa tới kiểu phương tiện Cú pháp chung: Content-Encoding : content-coding Mã hóa nội dung thuộc tính đối tương đươc xác định Request-URI Ví dụ: Content-Encoding: gzip Nếu mã hóa nội dung đối tương thông báo yêu cầu không đươc chấp nhận Server nguồn, Server phản hồi với mã trạng thái 415 (kiểu phương tiện không đươc hỗ trơ) Trường Content-Language: Trường miêu tả các ngôn ngữ tự nhiên người đọc dự định cho đối tương bao gồm Cú pháp chung: Content-Language : language-tag Nhiều ngơn ngữ có thể đươc liệt kê cho nội dung mà đươc dự định cho nhiều người đọc.Ví dụ: Content-Language: mi, en Mục đích Content-Language để cho phép người sử dụng để xác nhận tạo sự khác biệt các đối tương theo ngơn ngữ đươc ưa thích riêng người dùng Trường Content-Length: Trường dẫn kích cỡ phần thân đối tương, số thập phân hệ 8, đươc gửi tới người nhận hoặc, trường hơp phương thức HEAD, kích cỡ phần thân đối tương mà đươc gửi, có yêu cầu GET Cú pháp chung: ContentLength : DIGITS Ví dụ: Content-Length: 3495 Bất kỳ Conten-Length lớn giá trị có hiệu lực Trường Content-Location: Trường có thể đươc sử dụng để cung cấp vị trí nguồn cho đối tương đươc bao gồm thơng báo đối tương có thể truy cập từ vị trí riêng biệt từ URI nguồn đươc yêu cầu Cú pháp chung: Content-Location: absoluteURI | relativeURI Ví dụ: Content-Location: http://www.tutorialspoint.org /http/index.jsp Giá trị Content-Location định nghĩa URI sở cho đối tương Trường Content-MD5: Trường có thể đươc sử dụng để cung cấp hệ thống phân loại MD5 đối tương cho việc kiểm tra tính nguyên vẹn thông tin tới người nhận Cú pháp chung: Content-MD5 : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864 Ví dụ: Content-MD5 : 8c2d46911f3f5a326455f0ed7a8ed3b3 Hệ thống phân loại MD5 đươc tính toán hóa dựa sở nội dung phần thân thực thể, bao gồm bất cứ mã hóa nội dung mà đươc áp dụng, khơng bao gồm bất cứ mã hóa truyền tải đươc áp dụng tới phần thân thông báo Trường Content-Range: Trường đươc gửi với phần thân thực thể nội để xác định nơi toàn phần thân đối tương mà phần thân nội nên đươc áp dụng Cú pháp chung: Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos Các ví dụ các giá trị byte-content-range-spec, giả sử đối tương chứa tổng 1234 byte: The first 500 bytes: Content-Range : bytes 0-499/1234- The second 500 bytes: Content-Range : bytes 500-999/1234- All except for the first 500 bytes: Content-Range : bytes 500-1233/1234- The last 500 bytes: Content-Range : bytes 734-1233/1234 Khi thông báo HTTP bao gồm nội dung dãy đơn, nội dung đươc truyền tải với Content-Range, Content-Length số byte đươc truyền tải thực sự Ví dụ: HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif Trường Content-Type Trường dẫn kiểu phương tiện phần thân đối tương đươc gửi tới người nhận hoặc, trường hơp phương thức HEAD, kiểu phương tiện mà đươc gửi, có yêu cầu GET Cú pháp chung: Content-Type : media-type Ví dụ: Content-Type: text/html; charset=ISO-8859-4 Trường Expires Trường cung cấp Ngày/Thời gian sau phản hồi đươc cho hết hạn Cú pháp chung: Expires : HTTP-date Ví dụ: Expires: Thu, 01 Dec 1994 16:00:00 GMT Trường Last-Modified Trường ngày thời gian tại Server ban đầu tin sự biến đổi đươc chỉnh sửa lần cuối Cú pháp chung: Last-Modified: HTTP-date.Ví dụ: Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 2.4 HTTP status codes 2.4.1 HTTP status codes gì? HTTP status code (mã trạng thái) mã code server trả về sau lần gửi request Tất các request mà server nhận đươc đều đươc trả về response với mã code tương ứng Các HTTP status code chuẩn để server trả về HTTP status code giúp xác định request thành công hay không, thất bại thì nguyên nhân gì Ví dụ bạn hay gặp mã HTTP status code = 404 gửi request/truy cập đường link không tồn tại 2.4.2 Các loại HTTP status code HTTP status code gồm chữ số, đươc chia thành loại khác nhau, loại bắt đầu với chữ số khác mang ý nghĩa riêng: - 1xx (Informational – Thông tin): Các status code loại dùng để đơn giản thông báo với client server nhận đươc request Các status code đươc sử dụng - 2xx (Sucess – Thành cơng): Các status code loại có ý nghĩa request đươc server xử lý thành công - 3xx (Redirect – Chuyển hướng): Các status code loại có ý nghĩa server chuyển tiếp request tại sang request khác client cần thực việc gửi request để có thể hồn tất Thông thường trình duyệt nhận đươc status code loại tự động thực việc gửi request để lấy về kết - 4xx (Client error – Lỗi Client): Các status code loại có ý nghĩa có lỗi từ phía client gửi request Ví dụ sai URL, sai HTTP method, khơng có qùn truy cập vào trang… - 5xx (Server error – Lỗi Server): Các status code loại có ý nghĩa có lỗi từ phía server xử lý request Ví dụ server quá tải, hết nhớ, lỗi kết nối database… 1xx (Informational – Thông tin) - 100 Continue: Chỉ phần Request đươc nhận Server (có thể header Client cần gửi tiếp body), miễn không bị loại bỏ, Client nên tiếp tục với Request - 101 Switching Protocols: Server thay đổi protocol 2xx (Sucess – Thành công): - 200 OK: Request đươc tiếp nhận xử lý thành công - 201 Created: Request đươc tiếp nhận xử lý thành công tài nguyên mới đươc tạo server - 202 Accepted: Request đươc chấp nhận xử lý việc sử lý khơng hồn thành - 203 Non-autoriative Infomation: - 204 No content: Request đươc xử lý thành công server không trả về dữ liệu - 205 Reset content: Giống với 205 yêu cầu phía client phải thiết lập lại document view - 206 Partial Content: Server trả về phần dữ liệu 3xx (Redirect – Chuyển hướng): - 300 Multiple Choices: Một danh sách các link Người sử dụng có thể chọn link tới vị trí Có tối đa địa Ví dụ: List các file video với format khác - 301 Moved Permanently: Request tại các request sau đươc yêu cầu di chuyển tới URI mới - 302 Found: Trang đươc yêu cầu đươc di chuyển tới vị trí mới - 303 See Other: Trang đươc yêu cầu có thể đươc tả về URL khác cách sử dụng phương thức GET - 304 Not Modified - 305 Use Proxy - 306 Switch Proxy - 307 Temporary Redirect 4xx: (Client Error – Lỗi Client): - 400 Bad Request: Server không thể xử lý không xử lý các Request lỗi phía client (ví dụ Request có cú pháp sai) - 401 Unauthorized: Cần username, password để truy cập - 402 Payment Required: Mã chưa đươc định nghĩa - 403 Forbidden: Truy cập bị từ chối (ví dụ ip bị chặn) - 404 Not Found: Trang đươc yêu cầu không tồn tại tại thời điểm tại, nhiên có thể tồn tại tương lai - 405 Method Not Allowed: Trang đươc yêu cầu không hỗ trơ method request (ví dụ xử lý method POST, khơng xử lý method GET) - 406 Not Acceptable: Server có thể tạo Response mà không đươc chấp nhận Client - 407 Proxy Authentication Required: Bạn phải xác nhận với proxy server trước request đươc phục vụ - 408 Request Timeout: Request tốn thời gian dài thời gian Server đươc chuẩn bị để đơi - 409 Conflict: Request khơng thể đươc hồn thành vì sự xung đột - 410 Gone: Giống 404 tài nguyên/trang không tồn tại tương lai - 411 Length Required: Chưa định nghĩa trường “Content-Length” header request gửi - 412 Precondition Failed: Server không đáp ứng những điều kiện tiên Client Request - 413 Payload Too Large: Server không chấp nhận yêu cầu, vì đối tương yêu cầu quá rộng - 414 URI Too Long: URI đươc cung cấp quá dài để Server xử lý - 415 Unsupported Media Type: Server không chấp nhận Request, vì kiểu phương tiện không đươc hỗ trơ - 416 Range Not Satisfiable: Client yêu cầu phần dữ liệu khơng có sẵn server - 417 Expectation Failed: 5xx (Server error – Lỗi server) - 500 Internal Server Error: Một thông báo chung chung, đươc đưa Server bị lỗi bất ngờ (chủ yếu lỗi lập trình, kết nối database) - 501 Not Implemented: Server không hỗ trơ xử lý request 502 Bad Gateway: Server hoạt động gateway proxy nhận đươc Response không hơp lệ từ máy chủ nguồn - 503 Service Unavailable: Server tại khơng có sẵn (Quá tải đươc down để bảo trì) Nói chung trạng thái tạm thời - 504 Gateway Timeout: Server hoạt động gateway proxy không nhận đươc Response từ máy chủ nguồn - 505 HTTP Version Not Supported: Server không hỗ trơ phiên “giao thức HTTP” - Khá nhiều status code mình chưa hề gặp bao giờ, số chúng khó hiểu khá nhiều status code khác chưa đươc định nghĩa nhiên chuẩn để bạn áp dụng theo chứ khơng bắt buộc Ví dụ lập trình, server xử lý thành cơng, có trả về dữ liệu trả về status code 500 nhưung không đồng status code giữa client với server, bên phía client phải hiểu status code = 500 bị lỗi nữa CHƯƠNG DEMO CHƯƠNG TRÌNH 3.1 Chạy demo chương trình: Hình Giao diện mở cởn Hình Giao diện tắt server Hình 3 Giao diện thay đởi port Hình Giao diện thơng bao quản lý client Hình 5Giao diện chạy HTTP CHƯƠNG IV ĐÁNH GIÁ KẾT QUẢ ĐẠT ĐƯỢC VÀ HƯỚNG PHÁT TRIỂN ĐỀ TÀI 4.1 Đánh giá kết đạt đươc: Do trình độ có hạn thời gian đầu tư cho đề tài chưa nhiều nên đề tài đạt đươc kết sau: • Nắm bắt đươc số khái niệm phục vụ cho việc viết báo cáo • Phân tích đươc vai trị CNTT mơi trường hội nhập • Đánh giá thực trạng việc ứng dụng mạng các doanh nghiệp • Phân tích tồn toán từ bước mô tả quy trình quản lý doanh nghiệp đến việc phân tích dữ liệu các chức hệ thống • Thiết kế toán: Thiết kế đươc CSDL giao diện chương trình • Xây dựng phần mềm tương đối hoàn chỉnh so với yêu cầu đặt • Cho phép kết nối CSDL từ xa * Nhận xét về thiết kế CSDL • Là chương trình chạy mơi trường Windows nên ứng dụng có giao diện theo tiêu chuẩn Windows, vì vậy dễ sử dụng • Việc thiết kế dữ liệu đươc thực SQL Server, hệ quản trị chuyên dụng cho việc quản lý dữ liệu • Xây dựng thiết kế CSDL theo mơ hình quản lý doanh nghiệp, sử dụng hệ quản trị CSDL SQL Server máy chủ sử dụng ngôn ngữ Java cài đặt ứng dụng để tận dụng điểm mạnh hai ngôn ngữ * Nhận xét về báo cáo + Ưu điểm: • Đã cố gắng trình bày báo cáo cách khoa học có hệ thống những kiến thức hiểu biết thân, có tham khảo các tài liệu về các vấn đề có liên quan đến nội dung tìm hiểu, nghiên cứu • Cố gắng bám sát đề cương làm theo sự hướng dẫn ThS Nguyễn Văn Bình báo cáo đươc làm thời gian ngắn nên không thể tránh khỏi những sai sót, mong đươc sự đóng góp ý kiến các thầy để báo cáo đươc hồn thiện + Nhươc điểm: • Hệ thống chưa thực sự tối ưu, mới áp dụng cho mạng nội • Vấn đề bảo mật dữ liệu • Chưa đươc thử nghiệm mạng diện rộng • Do thời gian có hạn nên đề tài mới đáp ứng đươc phần yêu cầu toán • Báo cáo chưa giải đươc trọn vẹn những vấn đề phát sinh quá trình quản lý • Bài báo cáo chưa đạt tính thẩm mĩ cao, phong cách hành văn lủng củng, nhiều vấn đề chưa xác cần khắc phục quá trình phát triển, nâng cấp phần mềm giai đoạn sau * Thu hoạch cho thân - Về nhận thức: Trong thời gian làm đồ án đề tài hoàn thiện thêm kiến thức đươc học trường suốt học kì Báo cáo giúp chúng em tăng khả tư logic, có thể nghiên cứu độc lập vấn đề mà trước chúng em không quan tâm - Trau dồi những kinh nghiệm quý giá quá trình thiết kế, làm quen sử dụng các mô hình mạng 4.2 Hướng phát triển đề tài: Đây toán có nhiều tiềm quá trình hội nhập, để phát triển thànhmột hệ thống hồn chỉnh có thể đưa ứng dụng vào thực tế cách rộng rãi chươngtrình cần: • Cải tiến, hoàn thiện số chức chưa hoàn chỉnh chương trình • Xử lý vấn đề bảo mật dữ liệu: Phân quyền, cấp quyền cho nhóm ngườidùng • Nâng cấp hệ thống để có thể áp dụng quản lý doanh nghiệp mạng diện rộngvà sử dụng đươc các hệ quản trị khác • Thiết kế giao diện chương trình mang tính chun nghiệp • Phần mềm ứng dụng đươc áp dụng cho hầu hết các doanh nghiệp chứ không làdoanh nghiệp vừa nhỏ • Phát triển thành trang Web nhằm giúp các nhà quản lý có hội thúc đẩy sựphát triển doanh nghiệp quản lý công việc mình trực tiếp mạng nhằmphục vụ khách hàng cách nhanh chóng, thuận lơi KẾT LUẬN Với những kiến thức học trường, tham khảo các tài liệu chuyên ngành với sự nỗ lực thân sự giúp đỡ, hướng dẫn nhiệt tình ThS Nguyễn Thanh Cẩm, chúng em xây dựng đươc phần mềm quản lý vật tư, nhân sự cho các doanh nghiệp vừa nhỏ Chương trình chưa phải sản phẩm phần mềm hoàn hảo góp phần thể hướng nghiên cứu mới cho ngành công nghệ thông tin Rất mong nhận đươc những đánh giá, góp ý q thầy giáo các bạn để chương trình ngày hoàn thiện Một lần nữa chúng em xin chân thành cảm ơn! TÀI LIỆU THAM KHẢO [1] Nguyễn Phương Lan-Hoàng Đức Hải, Java lập trình mạng, Nhà xuất giáo dục, 2001 [2] Nguyễn cao Đạt , Giáo trình lập trình mạng, Trường Đại học Bách Khoa Hồ Chí Minh [3] Hồng Ngọc Giao, Lập trình Java nào?, Nhà xuất thống kê Hà Nội, 1998 [4] Nguyễn Phương Lan-Hoàng Đức Hải, Java ứng dụng Web với JSP/Serverlet, Nhà xuất lao động xã hội [5] http://www.java