HTTP 프로토콜 요청/응답

이제 java를 웹의 세계로 확장시켜 보도록 하겠습니다.

인터넷이나 인트라넷을 통해 웹브라우저에서 이용할 수 있는 소프트웨어를 웹 애플리케이션이라고 합니다. 웹 애플리케이션의 장점은 사용자의 컴퓨터에 굳이 소프트웨어를 배포해서 설치하지 않아도 유지 관리할 수 있다는 것입니다. 웹 애플리케이션은 이메일, 전자상거래, 인터넷 게시판, 게임 등 다양한 기능을 구현할 수 있습니다.

웹 애플리케이션이 동작하는 방식은 위 그림과 같습니다. 클라이언트가 웹브라우저를 통해 웹 서버에 필요한 자원을 요청합니다. 그러면 서버에서 사용자가 요청한 것을 넘겨 주게 됩니다. 자원(resource)이라고 하는 것은 HTML 페이지나 그림파일 혹은 PDF 파일이 될 수도 있습니다. 중요한 것은 클라이언트가 요청하면 서버는 그 요청에 응답한다는 것입니다.

클라이언트와 서버가 요청과 응답을 주고 받기 위해서는 서로 같은 규칙을 가지고 대화해야 합니다. 웹 애플리케이션에서 주로 사용하는 대화의 규칙은 HTTP(Hyper Text Transfer Protocol) 입니다.(FTP, SMTP 등이 있음)  클라이언트가 HTTP 요청을 보내면 서버는 HTTP 응답으로 대답합니다. HTTP는 이렇게 요청(Request)과 응답(Response)이라는 단순한 구조로 이루어져 있습니다.

웹서버는 요청에 대한 응답이 완료되고 나면 연결을 유지하지 않고 종료합니다. 이를 통해 서버에서 더 많은 클라이언트를 처리할 수 있지만 연속적인 작업을 처리해야 하는 채팅이나 게임등의 애플리케이션에는 적합하지 않습니다.(참고로 HTTP가 사용하는 포트번호는 80 입니다)

//웹 애플리케이션 제작에 Java 언어를 사용하는 규격으로 Java 서블릿과 JSP(Java 서버 페이지)가 있습니다.

요청메세지는 요청에 사용되는 HTTP 메소드, 필요한 자원의 위치를 나타내는 URL, 그리고 HTTP의 버전이 적시되어있는 요청라인, User-Agent(웹브라우져, 어떤 웹브라우져인지에 대한 정보가 담겨져 있음, 정보에 따라 어떻게 응답할 지), Accept-Language(웹브라우져가 처리할 수 있는 언어), Accept-Encoding(웹브라우져와 웹서버가 서로 데이터를 주고 받을 때 웹서버에서 데이터 응답을 받을 때 웹브라우져가 데이터를 받을 수 있는 인코더에 대한 내용) 같은 클라이언트의 요청 정보가 포함 된 요청헤더, 클라이언트에서 넘기는 파라미터 정보가 들어있는 바디로 구성되어 있습니다.

응답 메세지는 역시 HTTP의 버전과 응답 상태를 나타내는 상태 코드를 상태문을 통해 넘겨주고, Content-Type(서버가 보내는 데이터의 타입, MIME 타입), Content-Length 등 응답 정보가 들어있는 응답 헤더, 그리고 실제로 전달하는 컨텐츠가 들어있는 바디로 구성되어 있습니다.

상태코드 :

100번대 요청을 받았고 작업이 진행중

200번대 작업 성공

300번대 리다이렉션 요구

400번대 클라이언트 오류

500번대 서버 오류

HTTP가 요청할 때 요청라인에 요청 메소드가 포함 된 것을 봤었는데, HTTP는 몇 가지의 요청 메서드를 가지고 있습니다. 하지만 실제로 대부분의 경우 사용되는 것은 GET 메소드와 POST 메소드 입니다. GET과 POST 모두 클라이언트에서 서버로 파라미터값을 넘겨주고 필요한 페이지를 응답받을 수 있지만 약간의 차이점을 가지고 있습니다.

쉽게 말하면 GET은 가져오는 것이고 POST는 수행하는 것이다 라고 할 수 있습니다. GET은 서버로부터 정보를 조회하기 위해 설계된 메소드이고 POST는 리소스를 생성/변경 하기위해 설계된 메소드 입니다. 때문에 사용할 때는 이런 설계 원칙을 염두에 두고 사용해야 합니다.

GET은 요청을 전송할 때 필요한 데이터를 Body에 담지 않고, 쿼리스트링을 통해 전송합니다. URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터를 쿼리스트링이라고 부릅니다. 만약, 요청 파라미터가 여러 개이면 &로 연결합니다. 쿼리스트링을 사용하게 되면 URL에 조회 조건을 표시하기 때문에 특정 페이지를 링크하거나 북마크할 수 있습니다. 또 GET은 해당하는 페이지의 내용이 캐시될 수 있습니다. 하지만 URL에 파라미터를 담아 전송하기 때문에 길이의 제한이 발생하고, URL로 정보가 노출된다는 단점이 있습니다.

POST는 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송합니다. HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있습니다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있습니다. 이처럼 POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 합니다.

GET은 Idempotent, POST는 Non-idempotent하게 설계되었습니다. Idempotent(멱등)은 수학적 개념으로 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 말합니다. 다시말해 멱등인 것은 동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나야 합니다. GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않기 때문에 Idempotent합니다. 따라서 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아옵니다. 때문에 GET은 주로 조회를 할 때에 사용합니다. 예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하게 됩니다.

반대로 POST는 리소스가 생성, 변경 되기 때문에 Non-idempotent합니다. 서버에게 동일한 요청을 여러 번 전송해도 응답은 다를 수 있습니다.