HTTP(HyperText Transfer Protocol)

HTTP란?

텍스트 기반으로 데이터를 주고 받는 일종의 통신 약속이다.  프로그램들이 이 약속에 맞춰서 데이터를 서로 주고 받게 된다.

 

 

URL 구성도

URL 구성도

 

 

Request 및 Response

 

Accpet

Accpet: 컨텐츠 협상(Content negotiation) 서버와 어떤 데이터를 주고 받을지 명시

 

 

Cache-Control

 

Cookie

http는 stateless하다. 상태를 가지고 있지 않는다.

앞에 있는 http 요청이 성공해도 뒤에 있는 http요청이 실패할 수있고 앞에 있는 http 요청이 실패해도 뒤에있는 http요청은 성공 할 수도 있다.

 

따라서 내가 누군지를 알려줘야하는데 이때 사용할 수 있는 것이 쿠키이다.

쿠키는 일련의 문자열로 되어있으며 서버에서 먼저 보내주고 이후 클라이언트에서 해당 쿠키를 보내

서버는 누구에게 요청이 왔는지 알 수 있다. 

 

 

 

HTTP메서드와 REST API

GET

서버에서 데이터 가져오기

 

POST

일반적으로 데이터를 생성할 때

 

PUT

데이터 전체를 수정할 때

 

PATCH

데이터 일부분을 수정할 때

 

DELETE

데이터를 삭제할 때 

 

HEAD

라우터가 제대로 동작하는지 확인용
사실 GET으로 체크해도 되는데 데이터가 왔다갔다 하는것도
돈이 들기 때문에

OPTION
주로 cors때문에 사용
해킹이슈로 도메인이 다르면 요청이 기본적으로 제한되는데
이를 허용하기 위해 사용된다.

 

TRACE
프록시 서버 추적 + 최종 서버가 받은 메시지를 알려줘서
프록시 서버가 어떤 헤더를 바꿨는지 알 수 있게 한다.

 

안전한 메서드 / 안전하지 않은 메서드

안전한 메서드 : GET, HEAD, OPTIONS, TRACE

안전하지 않은 메서드 : POST, PUT, DELETE

 

멱등성 메서드

같은 것을 여러번 호출해도 서버에서는 한 번만 바뀐거나 다름이 없는 경우

GET, HEAD, OPTIONS, TRACE, PUT, DELETE

 

캐시

응답데이터를 저장하는 것

일반적으로 GET, HEAD와 같은 안전한 메서드를 캐싱할 수있다.

POST도 캐싱 할 수는 있지만 신선한 정보에 한해서만 가능하다. 일반적으로 캐싱하지 않는다.

 

 

상태코드(https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)

100번대

정보에 대한 응답 코드

• 100:  계속(continue) 요청 해도 된다는 응답코드
• 101: 웹소켓을 사용할 때 볼 수 있다. 서버가 http통신에서 웹소켓 통신으로 전환을 전달할 때 응답코드

 

200번대

성공에  대한 응답 코드

• 200: 일반적인 요청에 대한 성공 응답코드
• 201: 요청에 따라 자원이 성공적으로 생성되었을 때 응답코드  
• 204: 요청을 보냈을 때 응답 바디가 없는 경우 응답코드
• 206: 응답데이터가 일부분만 일때 응답코드

 

300번대

리다이렉트에  대한 응답 코드

• 301: 요청 주소 url이 영구적으로 바뀌었을때 새로운 url이 응답에 담겨있는 응답코드
• 302: 요청 주소가 일시적으로 수정 중임을 알려주는 응답코드
• 304: 캐싱에 대한 응답코드
• 307: 302와 동일하지만 http메서드가 변하면 안된다는 응답코드

 

400번대

클라이언트 에러에  대한 응답 코드

• 400: 일반적인  요청이 잘못되었다는 응답코드
• 401: 권한이 없다는 응답코드, ex:) 로그인해야하는 페이지일 경우
• 403: 클라이언트가 접근 권한이 없는 경우 응답코드, ex:) 로그인 해도 접근 불가능한 페이지 일 경우
• 404: 요청 주소에 따른 자원이 존재하지 않을 때
• 405: 클라이언트에서 메서드가 다르게 요청 되었을 때 응답코드
• 408: 요청을 서버에서 끊었을 때 응답코드
• 413: 서버에 데이터를 업로드 할 때 데이터가 너무 큰 경우 응답코드
• 414: 주소 길이 제한 설정 범위를 넘은 경우 응답코드
• 451: 요청 주소가 법적으로 금지되었을 때 응답코드

 

500번대

서버에러에  대한 응답 코드

• 500: 일반적인 서버 에러 응답코드
• 501: 요청에 따라 서버에서 처리가 되지 않을 때 응답코드, ex:) 서버에서 api가 만들어지지 않았을 때 
• 502: 서버 앞의 프록시, 게이트웨이, 방화벽 등에서 에러가 발생할때 응답코드
• 503: 의도적으로 서버를 중단하였을 때, 의도치 않게 서버가 중단되었을때 응답코드
• 504: 프록시, 게이트웨이에서 시간초과가 되었을 때 응답코드 

 

HTTP : 헤더와 바디(본문, payload ,content)로 구성

q=0.9 (q는 우선순위를 의미, 1에 가까울 수록 우선순위 ↑) 

 

헤더는 key: value 꼴, 한글 지원 X

GET /users HTTP/1.1

Host: heedo.com

Cookie: name=heedo

 

MIME Type(마임): 클라이언트가 원하는 콘텐츠 형식(대분류/확장자),

ex:) image/png, image/jpeg, video/mp4, application/json

 

Accept-Language: 문서를 어떤 언어로 할지

ex: )ko-KR,ko;q=0.9, en-US,en;q=0.7

 

Accept-Encoding: 어떤 것을 사용해서  압축할지

헤더랑 바디가 텍스트로 전달되니까 용량이 크다.

따라서 서버에서 압축 or 알고리즘을 사용하여 데이터를 보내주는데 이를 브라우저가 사용할 수 있는 압축 or 알고리즘을 명시

ex: ) gzip, deflate,  br(brutally) 

 

Accept-Charset: 문자열 어떤 방식으로 인코딩해서 줄지 

ex: ) utf-8, ascii, euc-kr

 

Keep-Alive: 3way-handshake를 맺은 후 timeout에 명시되어있는 시간동안 다시 handshaking 할 필요없이 연결을 유지 

ex: ) timeout=5

 

Date: 서버에서 메시지가 생성된 시간

 

Transfer-Encoding: 기본적으로 서버는 데이터를 한번에 보내주지만 데이터를 쪼개서 보내주었다는 것을 의미 

ex: ) chunked

 

Authorization

 

Referer: 이전 페이지가 어딘지 알려주는 것

 

Cookie : stateless한 http을 보완할 수있는 기능이며 쿠키란 서버에서 보낸 작은 정보파일로 브라우저에서 받은 뒤 다시 요청할때 헤더에 담아 보내주게 된다.

이를 통해 사용자가 누군지 알 수있게 된다.

• HttpOnly : 자바스크립트로 접근 할 수 있는가
• Secure: Https 일때만 전송가능
• Max-Age(쿠키유지시간 ) : 초 단위 (서버에서 메시지가 생성된 시간 기준. Expires와 둘다 있으면 Max-Age가 우선순위가 높음)
• Expires(쿠키유지시간): 정확한 시간 (서버에서 메시지가 생성된 시간 기준.)
• SameSite: Lax(기본값, 다른사이트에서 쿠키 저장 불가능, 링크로 접근할때만 가능), None(Secure 일때만 다른 쿠키 저장하여 사용 가능), Strict(같은 사이트에서만)

https://www.codeit.kr/tutorials/94/%EC%BF%A0%ED%82%A4%EC%9D%98%20SameSite%20%EC%98%B5%EC%85%98%EC%9D%B4%EB%9E%80%3F

 

Cache(DB,메모리,파일 => 캐시에 데이터를 얼머나 저장할지)

Cache-Control: max-age=000 (캐시 저장 시간 설정가능)

 

Cache Hit: 적중(저장소에 존재) 

  Cache가 너무 오래된 경우(캐시를 얼마나 오래 저장한 것인가)

• Cache가 오래됐는데 서버에 물어보니 변경이 없는 경우
  1. Cache꺼 쓰기, 304(Not modified)
• Cache가 오래됐는데 서버에 물어보니 변경이 있는 경우
• Cache가 오래됐는데 그냥 오래된거 주는 경우
  1. stale-while-revalidate : 일단 오래된 데이터 있으면 주고 서버한테 물어봐서 새 데이터가 있으면 업데이트 해놔
  2. stale-if-error: 서버가 에러를 보내도 일단 오래된 데이터 주고 지정한 기간이 지나면 에러를 발생

Cache Miss: 미적중(저장소에 미존재)

  서버로 데이터 요청

 

캐시 저장해도 되는데 신선도 검사가 필수

'Cache-Control ':'no-cache' 

 

캐시 저장하지마

'Cache-Control':'no-store'

 

캐시 유통기한 지나면 검사해

'Cache-Control':'max-age=80000, must-revalidate'

 

must-revalidate

must-revalidate 옵션은 HTTP 캐시 제어 헤더의 일부로, 클라이언트나 프록시 캐시가 만료된 리소스를 사용할 때 반드시 원 서버에 유효성을 확인해야 함을 지정합니다. 즉, 이 옵션은 캐시된 리소스가 만료되면 반드시 서버에 확인하여 최신 버전을 받아와야 함을 의미합니다.

주요 동작 원리:
캐시된 리소스 만료 후: must-revalidate가 설정된 경우, 클라이언트나 프록시 캐시는 만료된 리소스를 그대로 사용하지 않고 원 서버에 유효성 검사를 요청합니다. 서버가 리소스가 여전히 유효하다고 응답하면 캐시가 리소스를 계속 사용하고, 그렇지 않으면 최신 버전을 받아와서 사용합니다.
네트워크 오류 발생 시: 만료된 리소스가 있고 원 서버와의 연결이 불가능할 경우, no-cache만 있고 must-revalidate가 없으면 캐시는 만료된 리소스를 임시로 사용할 수 있지만, must-revalidate가 있으면 만료된 리소스를 사용할 수 없습니다.

즉 금융관련 중요데이터 같은 경우나 어떠한 경우에도 최신상태가 보장되어야 할 때는 항상 must-revalidate옵션이 필요하다.

 

캐시 신선도검사(캐시랑 서버의 데이터가 같은지)

If-Match: W/"eb226bab9dfb869841f1c57244dbaa13"

• etag를 보내줬을때 서버에서 보낸 것과 똑같다면 캐시에서 가져오기

If-None-Match: W/"eb226bab9dfb869841f1c57244dbaa13"

• etag를 보내줬을때 서버에서 보낸 것과 다르다면 캐시에서 가져오기

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

• Last-Modified값이 2022년 If-Modified-Since 값이 2021년이면 최신데이터니 캐시에서 가져다쓰기

 

CORS(corss origin resource sharing)

• access-control-allow-origin: 어떤 도메인의 요청 접근을 허용할지 설정
  1. * (와일드 카드로 모든 사이트 요청 허용)
  2. https://www.youtube.com (유튜브 사이트에서의 요청 허용)
• access-control-allow-credentials: true(서로 다른 origin일때 쿠키를 전달할지 말지 설정)

CORS에러(origin이 다르기 때문에 발생하는 브라우저에서만 발생하는 에러)

cors에러

cors에러 해결방법

1. 브라우저 => 같은 origin 서버요청
2. 브라우저 => proxy서버 => 다른 origin 서버요청