100년 뒤 개발자 한승규입니다.

HTTP 상태코드에 대해서 배워보자.

• 상태 코드

상태코드는 서버에서 클라이언트에게 보내며, 클라이언트가 보낸 요청에 대한 응답의 상태를 알려준다.

- 1XX (Informational) : 요청이 수신되어 처리 중인 상태

- 2XX (Successful) : 요청 정상 처리 상태

- 3XX (Redirection) : 요청을 완료하려면 추가 행동이 필요한 상태

- 4XX (Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 상태

- 5XX (Server Error) : 서버 오류, 서버가 요청을 처리하지 못하는 상태

1XX (Informational)

요청이 수신되어 현재 처리 중인 상태로, 현재는 거의 사용하지 않는다고 한다.

2XX (Successful)

클라이언트의 요청을 정상적으로 처리한 상태이다.

- 200 OK

가장 평범한, 요청 성공이다.

- 201 Created

요청에 성공해서 새로운 리소스가 생성이 된다.

- 202 Accepted

요청은 접수 되었으나, 처리가 완료되지 않은 상태이다.

- 204 No Content

서버가 요청을 정상적으로 수행했지만, 응답으로 보낼 데이터는 없다.

버튼을 눌러도 같은 화면을 유지해야 하는 상황에서 사용하며, 결과 내용이 없어도 204만으로도 성공을 인식할 수 있다.

3XX (Redirection)

요청을 완료하기 위해 추가적인 조치가 필요한 상태이다.

웹 브라우저는 3XX 응답의 결과에 Location 헤더가 있으면, 그 위치로 자동 이동한다.

- 300 Multiple Choices

- 301 Moved Permanently

- 302 Found

- 303 See Other

- 304 Not Modified

- 307 Temporary Redirect

- 308 Permanent Redirect

일단 흐름을 이해하면 이렇게 된다.

Location에 있는 페이지로 이동한다.

리다이렉션의 종류에는

- 영구 리다이렉션 (301, 308)

특정 리소스의 URI가 영구적으로 이동했을 때

원래의 URL을 사용하지 않으며, 검색 엔진 등에서도 변경을 인지한다.

301은 Moved Permanently로 리다이렉트 요청 메서드가 GET으로 변하고, 바디 부분이 제거될 수 있다.

308은 Permanent Redirt로 리다이렉트시 요청 메서도와 본문이 유지된다.

- 일시 리다이렉션 (302, 307, 303)

리소스의 URI가 일시적으로 변경된 상태이다.

302는 Found로 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.

307는 Temporary Redirect로 리다이렉트시 요청 메서드와 본문을 유지한다.

303은 See Other로 리다이렉트시 요청 메서드가 GET으로 변경

만약 POST 방식으로 결제를 한 후 웹 브라우저를 새로고침하면 중복 주문이 되는 문제가 생길 수 있다.

이렇게 DB에 주문데이터가 중복으로 2개 들어간다.

이 문제를 해결하기 위해서 POST로 결재 후에 결재 화면을 GET 메서드로 리다이렉트한다.

그러면 POST로 가지 않기 때문에 중복 결재가 되는 일이 없어진다. (조회만 하기 때문에)

- 특수 리다이렉션

304는 Not Modified로 캐시 목적으로 사용한다.

클라이언트에게 리소스가 수정되지 않았음을 알려, 로컬에 저장된 캐시를 재사용하게 한다.

4XX (Client Error)

클라이언트 요청에 따라 잘못된 문법등으로 서버가 요청을 수행할 수 없는 상태이다.

오류의 원인이 클라이언트에 있을 때 4XX 오류가 발생한다.

400은 Bad Request로 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없을 때이다.

401은 Unauthorized로 클라이언트가 해당 리소스에 대한 인증이 필요한 상태이다.

403은 Forbidden로 서버가 요청을 이해했지만 승인을 거부한 상태이다.

404은 Not Found로 요청 리소스를 찾을 수 없는 상태이다.

 5XX (Servor Error)

서버 문제로 오류가 발생한 모든 경우이다.

의도적으로 만드는 페이지는 아닐 것이다.

HTTP 메서드로 API를 설계해보자.

• 서버로 데이터 전송

서버로 데이터를 전달하는 방식은 2가지이다.

쿼리 파라미터, 메시지 바디 두 가지이지만 사실 GET과 GET을 제외한 나머지이다.

- 쿼리 파라미터

GET

데이터를 조회할 때 사용

- 메시지 바디

POST, PUT, PATCH

회원 가입, 상품 주문, 리소스 등록

클라이언트에서 서버로 데이터를 전송하는 상황은 데이터를 조회하거나, HTML form을 통한 데이터 전송, HTTP API를 통한 데이터 전송할 때이다.

차례로 살펴보자.

- 정적 데이터 조회

어차피 정적이기 때문에 쿼리 파라미터를 사용하지 않는다.

- 동적 데이터 조회

정적 데이터 조회와는 다르게 쿼리 파라미터를 사용하여 동적으로 결과를 받아온다.

- HTML form을 이용하여 데이터 전송

우선 HTML Form 전송은 GET, POST만 지원을 한다.

그러니 조회를 제외한 대부분은 POST를 사용한다.

POST 방식으로 파일도 전송이 가능하다.

이렇게 다른 종류의 여러 파일과 폼의 내용을 함께 전송하려면 Content-Type: multipart/form-data를 사용한다.

-HTTP API 데이터 전송

보통 이렇게 API 데이터만 전송하는 경우는 서버 to 서버로 사람이 보지 않을 때이다.

Content-type: application/json이 사실상 표준이 되었다.

• HTTP API 설계

우선 등록을 POST로 하는 POST 기반 등록부터 알아보자.

POST 기반 등록

- 학생 목록 /students -> GET

- 학생 등록 /students -> POST

- 학생 조회 /students/{id} -> GET

- 학생 수정 /students/{id} -> PATCH, PUT, POST

- 학생 삭제 /students/{id} -> DELETE

클라이언트는 등록될 리소스의 URI를 모르기 때문에 서버가 새로운 리소스 URI를 생성해준다.

그리고 이렇게 만든 리소스를 관리하는 디렉토리를 컬렉션이라고 한다.

PUT 기반 등록

- 파일 목록 /files -> GET

- 파일 조회 /files/{filename} -> GET

- 파일 등록 /files/{filename} -> PUT

- 파일 삭제 /files/{filename} -> DELETE

- 파일 ???  /files -> POST

POST 기반 등록과는 다르게 클라이언트가 리소스의 URI를 알고 있어야 한다.

클라이언트가 직접 리소스의 URI를 지정하기 때문에 클라이언트가 리소스를 관리하고 그 저장소를 스토어라고 한다.

HTML FORM 사용

- 학생 목록 /students -> GET

- 학생 목록 폼 /students/new -> GET

- 학생 등록 /students/new -> POST

- 학생 조회 /students/{id} -> GET

- 학생 수정 폼 /students/{id}/edit -> GET

- 학생 수정 /students/{id}/edit -> POST

- 학생 삭제 /students/{id}/delete -> POST

HTML FORM은 GET, POST만 지원한다.

그렇기 때문에 어쩔 수 없이 동사로 된 리소스 경로를 사용한다.

HTTP 메서드로도 어쩔 수 없는 경우에만 사용한다.

HTTP 메서드에 대해 알아본다.

• HTTP API를 만들어보자

만약 학생 정보 관리 API를 만들어라 라고 한다면

지금의 우리는 URI를

- 학생 목록 조회 /read-member-list

- 학생 조회 /read-member-by-id

- 학생 등록 /create-member

- 학생 수정 /update-member

- 학생 삭제 /delete-member

이렇게 설계할 것이다.

하지만 이렇게 설계하는 것은 좋지 않은 방법이다.

리소스가 식별이 되도록 설계를 해야한다.

여기서는 '학생 목록 조회'가 리소스가 아니라, 학생 그 자체가 리소스이다.

조회든, 수정이든 신경쓰지 않고 학생이라는 리소스만 식별하면 되기 때문에 학생 리소스를 URI에 매핑한다.

그럼 이렇게 리소스가 학생이라는 것을 알았는데, 조회나 수정은 어떻게 해야할까?

우리는 이 행위를 메서드에 넘기게 된다.

• HTTP 메서드

HTTP 주요 메서드 종류에는

GET : 리소스 조회

POST : 요청 데이터 처리, 주로 등록에 사용

PUT : 리소스를 대체, 해당 리소스가 없으면 생성

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

가 있다.

GET

리소스 조회

서버에 전달하고 싶은 데이터를 query를 통해 전달한다.

이렇게 서버에 리소스 조회를 한다.

POST

요청 데이터 처리

메시지 바디를 통해 서버로 요청 데이터를 전달하며, 들어온 데이터를 처리하는 모든 기능을 수행한다.

POST는 서버가 아직 식별하지 않은 새 리소스를 생성하거나 요청 데이터를 처리하거나, 아니면 다른 메서드로 처리하기 애매한 경우에 사용한다. (거의 만능이라고 한다)

PUT

기존에 있던 리소스를 대체한다.

리소스가 있으면 대체하고 리소스가 없으면 생성한다.

POST와의 차이점은 PUT은 클라이언트가 리소스의 위치를 알고 URI로 지정한다.

리소스를 대체하는 경우만 살펴보자.

PATCH

PUT과 같이 대체하는 것이 아니라 부분만 변경한다.

DELETE

리소스를 제거해버린다.

HTTP 메서드의 속성

- 안전

호출해도 리소스를 변경하지 않는다.

- Idempotent

호출 횟수에 관계 없이 같은 결과가 나온다.

- 캐시 가능

응답 결과 리소스를 캐시해서 사용해도 되는가?

이러한 속성들이 있다.

각각의 메서드들에 살펴보면

이제 부터 제대로 HTTP에 대해 알아보자.

• HTTP의 기본 개념

HTTP는 HyperText Transfer Protocol의 약자로

최근에는 이 HTTP 메시지에 모든 것을 전송하고 있다.

HTML 뿐만아니라 이미지, 영상, JSON 거의 모든 형태의 데이터를 전송 가능하다.

지금 가장 많이 사용하는 HTTP는 1.1 버전으로 1997년에 등장하게 되었다.

그 뒤로는 2, 3 버전이 나왔으며 현재는 섞어서 사용하고는 있지만 그래도 1.1 버전을 가장 많이 사용한다.

전에 배웠던 TCP, UDP 중에서 TCP가 가장 좋아 쭉 TCP를 사용할 것 같지만

3 버전 이후로는 속도가 빠른 UDP를 사용하며 2와 1.1도 점점 사용하는 추세이다.

• 클라이언트 서버 구조

JSP에서 공부했던 것처럼 Request와 Response 구조이다.

클라이언트는 서버에 요청을 보내고, 응답을 대기한다.

그러면 서버가 요청에 대한 결과를 만들어서 응답하는 것이다.

• 무상태 프로토콜

서버가 클라이언트의 상태를 보존하지 않는 것을 말한다.

무상태로 서버를 만들면 응답 서버를 쉽게 바꿀 수 있다.

예를 들어보자.

이렇게 상태를 유지하는 서버가 있다.

클라이언트는 첫번째 서버로 A 물품, 3개의 Request의 요청을 보낸다.

그러다가 갑자기 첫번째 서버에 고장이 나면

첫번째 서버에서 상태를 저장하고 있기 때문에 큰 일이 난다.

하지만 상태를 저장하지 않고 요청에 정보를 담아 보내는 무상태 서버라면 그냥 다른 곳으로 응답을 요청하면 된다.

어차피 고장난 서버에서 상태를 저장하고 있지 않기 때문에

그리고 같은 이유로 서버 확장에도 유리하다.

하지만 모든 것을 무상태로 설계 할 수는 없다.

로그인과 같은 경우에는 상태 유지로 설계를 해야한다.

• 비 연결성

연결을 유지하는 모델은 이렇게 응답을 받아도 TCP/IP 연결을 계속 유지한다.

하지만 연결을 유지하지 않는 모델은 응답을 받으면 TCP/IP 연결을 종료한다.

HTTP는 기본이 연결을 유지하지 않는 모델이다.

어차피 일반적으로 초 단위 이하의 빠른 속도로 응답하기 때문이다.

덕분에 서버 자원을 매우 효율적으로 사용할 수 있다.

하지만 아무리 빠른 속도로 응답을 하더라도 3 way handshake 시간이 추가된다.

또한 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css등의 자원이 함께 다운로드 된다.

그렇기에 HTTP도 지속 연결을 사용하기도 한다.

HTTP 지속연결은 아래와 같이 자원을 한번에 받고 연결을 종료하는 방법이다.

• HTTP 메시지

위에서 HTTP 메시지에 모든 것을 전송할 수 있다고 했었다.

그럼 그 메시지들을 한 번 보도록 하자

이게 가장 대표적인 예시로 요청과 응답에 사용했던 HTTP 요청 메시지, HTTP 응답 메시지이다.

HTTP 메시지의 기본 구조는 아래와 같다.

이 기본 구조만 지키면 되는 것이다.

그럼 이 구조들을 하나씩 살펴보자.

시작 라인

이 부분은 요청과 응답이 살짝 다르다.

우선 요청부터 보자면

request-line = [method] [request-target] [HTTP-version]엔터

위의 요청 메시지에서 HTTP method는 GET이었고, 요청 대상은 /search?q=hi&hl=ko이며 HTTP/1.1임을 나타내고 있다.

method는 서버가 수행해야 할 동작을 지정하며

종류에는 GET, POST, PUT, DELETE가 있다.

request-target은 절대경로[?query]의 형식으로 경로와 넘길 커리를 지정한다.

HTTP-version은 사용한 HTTP 버전을 나타낸다.

응답을 보면

status-line=[HTTP-version] [status-code] [reason-phrase]

HTTP-version은 위처럼 사용한 HTTP 버전이다.

status-code는 성공과 실패를 나타낸다.

200은 성공, 400은 클라이언트 요청 오류, 500은 서버 내부 오류등을 나타낸다.

reason-phrase는 사람이 이해할 수 있도록 설명을 적는 곳이다.

헤더

header-field=[field-name:] [field-value]의 구조를 가진다.

HTTP 전송에 필요한 모든 부가정보를 담는다.

예를 들면 메시지 바디의 내용, 메시지 바디의 크기....

HTTP 메시지 바디

실제 전송할 데이터를 담는다.

HTML 문서, 이미지, 영상, JSON등을 모두 전송 가능하다.

URI와 웹 브라우저 요청에 대해 알아보자.

URI(Uniform Resource Identifier)

URI라고 하면 뭔가 URL의 오타같이 느껴질 것이다.

URL은 많이 봤어도 URI는 처음 봤을 것이다.

URI는 URL(locator), URN(name)로 나뉘고 URL은 그 종류일 뿐이다.

URI는

Uniform: 리소스를 식별하는 통일된 방식

Resource: 자원, URI로 식별할 수 있는 모든 것

Identifier: 다른 항목과 구분하는데 필요한 정보

의 약자이다.

URL: Uniform Resource Locator

URN: Uniform Resource Name

URL은 리소스가 있는 위치를 지정하고 URN은 리소스에 이름을 부여한다. 하지만 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았기 때문에 보통 URL을 사용한다.

URL 분석

https://www.naver.com/search?q=hi&hl=ko 

를 타겟으로 분석해보자.

일단 URL의 전체 문법은

scheme://[userinfo@]host[:port][/path][?quert][#fragment] 이다.

• scheme

주로 프로토콜(어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙, http와 https 등등) 사용

http는 80포트, https는 443 포트를 사용하며 이 포트들은 생략이 가능하다.

• userinfo

URL에 사용자정보를 포함해서 인증... 한다고 한다.

거의 사용하지 않기 때문에 그냥 넘어가도 될 듯 하다.

• host

호스트명이다.

주로 도메인명을 사용하지만 IP 주소를 직접 사용할 수 있다.

• port

어디에 접속하는지를 나타내는 포트이다.

• path

리소스 경로이다.

ex) /home/target1.jpg

• query

key=value형태로 나타낸 데이터이다.

?로 시작을 하며, 추가 할 때마다 &로 이어주면 된다.

• fragment

서버에 전송하는 정보가 아닌 html 내부 북마크 등에 사용한다.

기본 문법을 알아보았으니, 타겟 주소로 분석을 해보자.

우선 www.google.com을 DNS 서버에서 조회해 IP 주소를 얻은 후 그곳으로 보낼 HTTP 요청 메시지를 생성한다.

그 때 HTTP 요청 메시지는

이렇게 만들어 질 것이다.

그 HTTP 요청 메시지가 단계를 거치며 포장이 되어 서버로 갈 것이다.

위 그림은 그 과정을 나타낸 것이다.

그 때 만들어진 패킷은

이렇게 메시지를 감싸서 만들어지게 될 것이다.

이렇게 만들어진 패킷을 서버에 보내면 서버에서 확인을 하고 응답 메시지를 만들어 보낼 것이다.

그러면 클라이언트는 이 응답 메시지를 웹 브라우저에서 렌더링하여 화면을 표시할 것이다.

HTTP 1일 차로 인터넷 네트워크에 대해서 공부한다.

• 인터넷 통신

만약 컴퓨터 두 대가 직접적으로 연결이 되어 있다면

이렇게 직접 통신을 하면 될 것이다.

하지만 수많을 컴퓨터들이 있는 인터넷 내에서는 어떻게 통신을 할까?

이렇게 수많은 노드들을 거친 후에 서버에 도착해야 할 것이다.

과연 어떤 방법으로 서버를 찾아가게 될까?

• IP

그 방법으로는 컴퓨터마다 고유의 번호를 부여하고 그 번호로 찾아가게 하는 것이다.

고유의 번호를 IP 주소라고 한다.

지정한 IP 주소에 패킷이라는 통신 단위로 데이터를 저장하게 된다.

이렇게 전송 데이터에 IP 관련된 정보를 넣어서 감싼 단위를 패킷이라고 한다.

패킷 안에는 IP 정보가 들어가 있기 때문에 해당 정보를 이용하여 목적지까지 패킷을 운반한다.

하지만 이 IP 프로토콜에도 한계가 있다. 

- 비연결성

만약 패킷을 받을 대상이 없거나 서비스 불가 상태여도 데이터를 전송한다.

- 비신뢰성

데이터가 중간에 소실될 수 있고, 패킷이 순서대로 오지 않을 수도 있다.

- 프로그램 구분

같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면 어느 애플리케이션으로 가야 하는지 알 수 없다.

• TCP, UDP

해당 방법을 TCP에서 해결할 수 있다.

프로토콜 계층을 살펴보면

인터넷 프로토콜 스택의 4계층이다.

이거를 사용하는 단계까지 같이 표현을 해보자면

이렇게 나타내진다.

데이터를 전송할 때에는 이 모든 과정을 거쳐 전송하게 된다.

IP 패킷으로 포장하기 전에 TCP 하나를 추가하게 되는 것인데

TCP는 이전에 IP 프로토콜에서 생겼던 문제들을 해결할 수 있다.

TCP 특징

- 연결지향(TCP 3 way handshake, 가상연결)

데이터를 전송하기 전에 서버에 접속 요청을 보낸 후, 서버에서 요청 수락을 하고 서버에서 클라이언트로 접속 요청을 보내면 그것에 응답하여 서로 연결이 된 것을 확인한 후 데이터를 전송하는 방법이다.

클라이언트와 서버 간에는 연결이 된 것을 확인할 수 있지만, 그 중간의 노드들은 접속이 된 것을 알지 못하기 때문에 가상 연결이라고도 한다.

- 데이터 전달 보증

데이터를 수신하면 데이터를 수신한 곳에서 송신한 곳으로 수신이 완료되었음을 알리는 신호를 보낸다.

이렇게 하면 데이터가 전달되었다는 것을 보증할 수 있다.

- 순서 보장

순서가 맞지 않는다면, 맞지 않는 곳에서부터 재전송을 요청하여 순서대로 도착함을 보장한다.

이렇게 TCP에 대해 알아보았다.

UDP는 이와 정반대의 특징을 가지는데

연결지향, 데이터 전달 보증, 순서 보장의 특징을 가지지 않아 IP와 거의 비슷하지만 속도가 훨씬 빠르다.

• PORT

이렇게 한 번에 둘 이상 연결할 경우가 있다.

이럴 때에는 어떤 데이터가 어디에 쓰이는지 어떻게 구별할 수 있을까?

이럴 때에는 위에 같이 포장되어 있는 PORT의 정보를 이용한다.

이렇게 포트 번호를 보고 어디에서 온 데이터인지 구별하여 사용한다.

• DNS

IP는 숫자로만 구성되어 있어 기억하기 어렵다.

우리가 웹 사이트에 접속할 때마다 저 번호를 기억해서 치고 들어가면 상당히 힘들 것이다.

그렇기 때문에 우리는 DNS(Domain Name System)을 사용한다.

도메인 명을 IP 주소로 변환해 주는 방법이다.

우리가 google에 접속하려고 하면 구글의 google.com을 치고 접속한다.

그러면 도메인 서버에서 해당 도메인명에 일치하는 IP주소를 찾아 접속을 해준다.

그러면 우리는 IP 주소를 몰라도 google에 접속할 수 있게 되는 것이다.