[HTML] HTTP에 대해서

HTTP에 대해서

 

Http란?

• HTTP는 HyperText Transfer Protocol의 약자로 주로 HTML과 같은 HyperText문서를 주고 받기 위해 만들어 졌고, 최근에는 HTML뿐 아니라 모든 웹 관련 API통신에 이용하고 있는 통신 프로토콜입니다.

HTTP프로토콜은 비연결성(Connectionless)과 무상태성(Stateless)의 특징을 가지는 통신 프로토콜입니다.

 

●비연결성(Connectionless) : 처음 연결을 맺은 후 요청(Request)과 한 번의 응답(Response)이후 연결이 종료됩니다.

매 요청마다 다시 연결을 맺습니다.

매번 연결을 맺어 느려지는 것을 보완하기 위해 KeepAlive와 같은 속성을 활용할 수 있습니다.

 

●무상태성(Stateless) : 프로토콜에서 Client의 상태를 기억하지 않는다.

Client의 상태를 보관하기 위해 쿠키나 세션, JWT토큰 등을 이용하여 Client의 상태를 유지합니다.

 

비연결성과 무상태성이라는 특징은 통신을 하기 위한 소프트웨어 구조를 단순하게 만들어주어 몇몇 성능적 이슈에도 불구하고 가장 인기있는 통신 프로토콜이 되게 해주었습니다.

Cookie와 Session

 

쿠키(Cookie)

• HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일.

HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요 시 정보를 참조하거나 재사용 할 수 있다.

 

쿠키 특징

• 이름, 값, 만료일(저장기간) ,경로 정보로 구성되어 있음
• 클라이언트에 총 300개의 쿠키를 저장할 수 있음
• 하나의 도메인 당 20개의 쿠키를 가질 수 있음
• 하나의 쿠키는 4KB(=4096byte)까지 저장 가능

 

쿠키의 동작 순서

• 클라이언트가 페이지를 요청한다.(사용자가 웹사이트에 접근)
• 웹 서버는 쿠키를 생성
• 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
• 넘겨받은 쿠키는 클라이언트가 가지고 있다가(로컬PC에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송
• 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송

HTTP 구조

• HTTP 구조를 이해하면 API를 설계할 때 더 좋은 구조로 API를 설계할 수 있고, 다른 사람이 설계한 API나 소스코드를 보는데 도움을 매우 많이 주기 때문에 꼭 알아야 한다.

 

요청 메시지

• 요청 메시지는 start-line, header, empty-line, body로 구성되어 있다.

 

start-line

• start-line은 HTTP METHOD와 URL, 그리고 protocol version에 대해서 기술되어 있습니다.

● HTTP METHOD : GET, POST, PATCH, PUT, DELETE와 같은 http method를 적는 부분.

Server에서 요청을 Routin할때 사용되며 주로 각각의 Method는 차례대로 READ, CREATE, UPDATE(part), UPDATE(all), DELETE를 의미한다.

 

● url : 리소스를 요청하는 주소를 의미한다. https://blog.naver.com/{리소스경로} 와 같이 전체 주소를 입력하기도 하며, 같은 HOSY에서 요청을 보낼 경우 /{리소스경로} 와 같이 PATH만 요청하기도 한다.

 

● protocol version : http의 버전을 의미한다. HTTP/1.1을 가장 많이 사용하며 최근에는 HTTP/2의 사용이 늘고 있다.

 

Header

• Header는 요청에 대한 정보, 응답에 대한 요청, 인증 정보, 접속 정보 등 요청에서 필요한 다양한 요소를 담을 수 있는 공간입니다.

key, value로 구성되어있다.

 

● Content-Type : Body에 들어가는 요청 전문의 Type을 의미한다.

Json을 보낼때는 application/json, 이미지나 파일을 전송할때는 multipart/form-data,

바이너리가 없는 form을 전송할때는 application/x-www-form-urlencoded,

타입이 없는 text를 전송할때는 plain/text를 사용한다.

이 부분을 잘못 체크해서 에러나는 케이스가 많으니 이유없이 API호출이 실패할때 한번 확인해보기!

 

● Accept : 응답 받을 메시지 타입을 명시한다.

 

● connection : 주로 keep-alive로 셋업한다.

keep-alive로 셋업하면 매 요청시 커넥션을 다시 맺지 않고 커넥션을 유지하기 때문에 성능향상을 기대할 수 있다.

 

● User-Agent : 사용자의 기기를 식별할 수 있다.

기기 / OS / 브라우저 별 예외를 처리할 때 많이 사용되며 사용자 통계를 수집하기 위해서도 사용된다.

 

● Authorization : 인증 정보를 담을 때 사용하는 Header이다.

주로 인증 토큰을 Authorization Header에 담아 보낸다.

 

● Cookie : 개인 브라우저에 저장되는 Cookie 정보를 보낼 때 사용하는 Header.

 

● session-id : Session에 대한 id값을 지정하는 부분

 

Cookie나 session-id의 경우 프레임워크나 라이브러리에서 처리해주기 때문에 직접 셋업할 일이 많지 않지만 해당 header의 존재를 알고 있다면 postman이나 restclient사용 시 해당 정보를 header에 넣어 시뮬레이션 하는데 사용할 수 있다.

 

empty-line

• Header와 Body를 구분하는 부분

 

Body

• 메시지 전문이 들어간다.

Header의 Content-Type과 꼭 Type을 맞춰줘야 하한다.

HTTP Method별로 Get과 Delete는 body를 쓰지 않기 때문에 꼭 확인하기!

응답

• 요청에 따른 응답 메시지 부분. 전체 구조는 요청과 똑같지만 내용의 차이가 조금씩 있다.

 

start-line

• 응답의 start-line에는 protocol version, Http Status code와 Http Status가 담겨있다.

Http Status는 요청에 대한 응답 상태로 200번대는 성공, 400번대는 사용자 요청 에러, 500번대는 서버에러를 의미한다.

에러 메시지 응답시 에러 코드를 body에 담아 보낼 수도 있지만 센스있게 Http Status를 사용해보는 것도 좋다.

 

Header

• 요청과 우사하나 서버에 대한 정보를 건네준다. 사용자의 cookie나 session을 초기화 하는데도 이용한다.

empty-line과 body는 요청과 동일!!

응답코드