JavaWeb

Title: JavaWeb

JavaEE

JavaEE Specification

J avaEE specification is the new name for the J2EE specification, which was originally called the J2EE specification. Its full name is Java 2 Platform Enterprise Edition, an industry standard jointly created and widely recognized by SUN and other vendors (members of the JCP). The rename to JavaEE was intended to make clear that J2EE simply means Java Enterprise applications. In a talk at the 2004 China Software Technology Conference Ioc about micro‑containers (the implementation principle of the Jdon framework), it was pointed out: we need a cross‑J2SE/WEB/EJB micro‑container to protect our core business components and keep them alive, rather than being tied to a specific J2SE/J2EE version. The change from J2EE to Java EE reflects this industry sentiment.

The JavaEE specification is a collective term for many Java development technologies, all inherited from J2EE. It comprises 13 technical specifications, such as JSP/Servlet, JNDI, JAXP, JDBC, JNI, JAXB, JMF, JTA, JPA, EJB, etc.

The JCP (Java Community Process) is an open international organization founded in 1998, composed mainly of Java developers and licensees, responsible for evolving and updating the specifications.

Official website: ​

JavaEE versions continue the J2EE numbering but drop the old naming scheme. J2EE versions ran from 1.0 to 1.4, while JavaEE starts at JavaEE 5; the latest version is JavaEE 8.

For more details: ​

Web Overview

In computing, “Web” refers to a network. The WWW we use is made up of three words: World Wide Web, which means “World Wide Web.” For example, in the “W3School Complete Tutorial,” W3C stands for the World Wide Web Consortium, an organization that exists to help us obtain resources on the Internet. Those resources are hosted on websites. By entering a site’s address (URL), we can access the resources it provides. Everything we can reach online—whether on a LAN or WAN—is a resource; different types of resources simply render differently.

Resource categories

• Static resources are unchanging files served to users—everyone sees the same content regardless of time or identity. Examples include news articles, user manuals, functional specifications, as well as the HTML, CSS, JavaScript, images, and multimedia that developers write.
• Dynamic resources are generated by programs, so the content can vary by time or user role. For instance, on CSDN you can download files only after logging in and having enough points; guests cannot. JSP, Servlet, PHP, ASP, etc., are dynamic resources.

LAN vs. WAN

• WAN refers to the World Wide Web, i.e., the Internet.
• LAN is a network confined to a limited area; beyond that area the network is unavailable.

Application server vs. Web server

Application servers and Web servers are two distinct components used to build Web applications, but they work closely together.

• A Web server (e.g., Apache, Nginx, IIS) primarily serves static files such as HTML, CSS, and JavaScript, sending them to browsers. It can also cooperate with an application server (via reverse proxy, load balancing, etc.) to provide caching, dynamic content generation, and other advanced features.
• An application server runs on top of a Web server and handles business logic and data processing. Common application servers include Tomcat, JBoss, WebLogic, Node.js, etc. They typically support one or more programming languages (Java, Python, Ruby, …) and provide frameworks and APIs for rapid development. Application servers generate dynamic content, handling database access, file uploads, authentication, and other complex tasks.

In short, the Web server delivers static files and handles load‑balancing, while the application server processes business logic and produces dynamic content for the user.

System Architecture

Basic structural categories: C/S (client‑server) and B/S (browser‑server).

Technology‑selection models: Model 1, Model 2, MVC, and three‑tier + MVC.

Deployment styles: monolithic, vertically split, distributed, stream‑processing, micro‑services.

C/S Architecture

Client‑server style. The system diagram is:

B/S Architecture

Browser‑server style. The system diagram is:

Differences and pros/cons

• Differences

  • Hardware environment: C/S usually runs on a dedicated or small‑scale network (LAN) and requires a client installation. B/S runs over the WAN, needing only an OS and a browser.
  • Security: C/S is generally more secure because the user base is fixed, allowing tighter data protection.
  • Maintenance: B/S is easier to upgrade and maintain; C/S updates are more cumbersome.

• Pros

  • C/S: Leverages the client PC’s processing power, allowing many tasks to be performed locally before sending results to the server, resulting in fast client response.
  • B/S: Lower overall cost, easy maintenance, strong distribution, simple development, no special client software required—any internet‑connected computer can access it, and scaling is straightforward.

HTTP

Key Concepts

HTTP (Hyper Text Transfer Protocol) is built on TCP/IP and defines a request‑response rule set (question‑answer mechanism, handshake).

HTTP is a stateless, connection‑oriented protocol: the server does not retain client state between requests, so opening a page now has no relation to a previous visit.

Note: “Stateless” does not mean HTTP uses UDP, and “connection‑oriented” does not imply HTTP is TCP.

Purpose: Defines how web browsers and web servers exchange data and the content of that data.

Interaction flow: Browser sends a request → Server sends a response

• Request (request line, headers, body)
• Response (status line, headers, body)

URL vs. URI (see details below)

• URL (Uniform Resource Locator)
  Example: http://127.0.0.1:8080/request/servletDemo01

  • http: scheme
  • 127.0.0.1: host name
  • 8080: port
  • request/servletDemo01: path to the requested resource

• URI (Uniform Resource Identifier)
  Format: /request/servletDemo01

• Difference: URL - HOST = URI. A URI is an abstract identifier; a URL locates a resource by address, while a URI identifies it by name. Any uniquely identifiable resource is a URI; when the access method (e.g., protocol) is added, it becomes a URL.

What happens from typing a URL to receiving a response?

1. Parse and encode the URL.
2. DNS resolution: first check the hosts file, then the local DNS cache, then query the local name server, root server, TLD server, and authoritative server until an IP address is returned. The IP is cached by both the OS and the browser.
3. Establish a TCP connection via the three‑way handshake.
4. Send the HTTP request.
5. Server processes the request and returns a response.
6. Close the TCP connection (unless keep‑alive is used).
7. Browser parses and renders the page.

Recommended reading: ​

Version Differences

Overview

• HTTP/0.9 supports only GET and no request headers.
• HTTP/1.0 uses short connections by default (one TCP connection per request) and supports GET, POST, HEAD.
• HTTP/1.1 uses persistent connections (multiple requests per TCP connection); supports PUT, DELETE, PATCH, etc.; adds the Host header for virtual hosting; supports range requests for resumable downloads.
• HTTP/2.0 introduces multiplexing (multiple requests on one TCP connection), server push (all related resources sent together), binary framing (fewer parsing errors, more efficient than text‑based HTTP/1.x), and header compression.
• HTTP/3.0 is QUIC (Quick UDP Internet Connections), a UDP‑based transport.

HTTP 1.0 vs. HTTP 1.1

• Connection handling: HTTP/1.0 defaults to short connections; each resource (HTML, CSS, etc.) requires a new TCP handshake, which is costly. HTTP/1.1 defaults to persistent connections (Connection: keep-alive) with a timeout, and supports pipelining (sending multiple requests without waiting for each response).
• Status codes: HTTP/1.1 adds 24 new codes, e.g., 409 Conflict, 410 Gone.
• Caching: HTTP/1.0 relies on If-Modified-Since and Expires; HTTP/1.1 adds ETag, If-Unmodified-Since, If-Match, If-None-Match, etc.
• Bandwidth optimization: HTTP/1.1 introduces the Range header, allowing partial content (206 Partial Content) and resumable downloads.
• Host header: HTTP/1.0 assumes a unique IP per server, so the host name isn’t sent. HTTP/1.1 adds the Host header to support virtual hosting on a single IP.

HTTP 1.1 vs. HTTP 2.0

• Binary framing: HTTP/1.1 is text‑based; HTTP/2 uses a binary format for more efficient parsing.
• Multiplexing: Multiple requests/responses can be interleaved on a single connection, eliminating head‑of‑line blocking.
• Header compression: HTTP/2 separates headers into frames and compresses them using HPACK, sending only differences for subsequent requests.
• Server push: The server can proactively send resources without an explicit client request.

Secure Requests

HTTP vs. HTTPS

• Ports: HTTP defaults to 80, HTTPS to 443.
• Security: HTTP runs over TCP with plaintext transmission; neither side can verify the other’s identity. HTTPS runs HTTP over SSL/TLS (which itself runs over TCP); all traffic is encrypted with symmetric keys, while the symmetric key is protected by the server’s asymmetric certificate.
• Resource usage: HTTPS consumes more server resources than HTTP.

Symmetric vs. Asymmetric Encryption

• Symmetric encryption: Same key for encryption and decryption; the key must be shared with the client, which can be intercepted (analogous to giving someone a locked box and the key). Common algorithms: DES, AES.

  • Pros: Fast.
  • Cons: Secure key exchange is difficult.

• Asymmetric encryption: Uses a public key for encryption and a private key for decryption (or vice‑versa). Public key is openly distributed; private key remains secret. Common algorithms: RSA, DSA.

  • Public‑key encryption: Guarantees confidentiality because only the private key holder can decrypt.
  • Private‑key encryption: Provides authenticity; if a public key can decrypt a message, it proves the sender possessed the corresponding private key.
  • Pros: Secure key distribution.
  • Cons: Slower.

Hybrid approach

1. Use asymmetric encryption to securely transmit a symmetric secret key.
2. Use that symmetric key for the bulk of the data transfer (efficient).
3. Conceptually: “lock the lock.”

Glossary

• Hash algorithm: Computes a hash value of content; the receiver recomputes the hash to verify integrity.
• Digital signature: An encrypted hash attached to a message, created with a private key; the public key can verify it, ensuring the message wasn’t tampered with and confirming the sender’s identity.
• Digital certificate: An authority‑issued credential that binds a public key to a domain name.

HTTPS workflow

1. Client initiates an HTTPS request to the server’s port 443, sending supported cipher suites and hash algorithms.
2. Server presents its digital certificate (signed by a CA). The certificate contains the server’s public key, domain, issuing CA, expiration, etc.
3. Client validates the certificate using the CA’s public key (pre‑installed in the browser/OS).
4. If valid, the client generates a random “session key” (the symmetric key) and encrypts it with the server’s public key, sending it to the server (first encrypted HTTP request ends).
5. Server decrypts the session key with its private key, then uses that symmetric key to encrypt/decrypt subsequent data.
6. The client and server now exchange encrypted HTTP messages using the shared symmetric key, completing the HTTPS transaction.

References:
https://www.cnblogs.com/linianhui/p/security-https-workflow.html
https://www.jianshu.com/p/14cd2c9d2cd2 ​

Request Section

Components of an HTTP request

• Request line: Always the first line.
• Headers: From the second line up to the first empty line.
• Body: Starts after the empty line and continues to the end (absent for GET).

Request methods

• POST
• GET

GET vs. POST

• Purpose: GET retrieves resources; POST submits an entity.
• Parameters: GET parameters appear in the query string of the URL; POST parameters are placed in the request body (though POST can also send URL parameters). The presence of a body does not guarantee higher security—tools like Fiddler can still capture it.
• Safety: Safe methods do not change server state (read‑only). GET is safe; POST is not. Other safe methods include HEAD, OPTIONS. Unsafe methods include PUT, DELETE.
• Idempotence: Repeating the same request yields the same server state. Safe methods are also idempotent. Under correct implementation, GET, HEAD, PUT, DELETE are idempotent; POST is not.
• Cacheability:
  • The HTTP method itself must be cacheable (GET, HEAD). PUT, DELETE are not; POST is generally not cacheable.
  • The response status code must be cacheable (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501).
  • The response’s Cache-Control header must not forbid caching.

---

Originally written by Li Wei (李唯_) and published in Chinese on 后端技术栈全书 (Full-Stack Backend Engineering). Translated and adapted for DriftSeas with permission.