HTTP 프로토콜(HyperText Transfer Protocol): 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜
TCP/IP위에서 작동함
클라이언트에서 요청(request)을 보내면 서버는 요청을 처리해서 응답(response)함
작동방식의 특징
HTTP는 connectionless방식으로 작동함. 서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버린다. 자원 하나에 대해서 하나의 연결을 만든다.
장점: 불특정 다수를 대상으로 하는 서비스에 적합한 방식. 많은 사람들이 웹 서비스를 사용해도 접속유지는 최소한으로 할 수 있기 때문에, 더 많은 유저의 요청을 처리할 수 있다.
단점: 연결을 끊어버리기 때문에, 클라이언트의 이전 상태를 알 수 없다. 이런 특징을 stateless라고 함. 클라이언트의 이전 상태 정보를 알 수 없게 되면, 웹 서비스를 하는데 문제가 생김. 로그인을 성공해도 로그 정보를 유지할 수 없다.
->쿠키를 통해 해결가능
Request Message
공백을 제외하고 3가지 부분으로 나눠짐
startline
headers
body
1.start line
Http Request Message의 시작 라인으로 3가지 부분으로 구성됨
Http method
Request target
HTTP version
Get/test.html Http/1.1
[Http Method][Request target] [Http version]
HTTP method
-GET, POST, PUT, DELETE 등으로 이뤄져 있음
GET은 존재하는 자원에 대한 요청을, POST는 새로운 자원을 생성하는 기능을, PUT은 존재하는 자원에 대한 변경을, DELETE는 존재하는 자원에 대한 삭제와 같은 기능을 가지고 있음.
나중에 더 자세히 다룰 예정
Request target은 HTTP Request가 전송되는 목표 주소
HTTP version은 version에 따라 Request 메시지 구조나 데이터가 다를 수 있어서 Version을 명시함
- headers
해당 request에 대한 추가정보를 담고 있는 부분
ex. request 메시지, body의 총길이 등 key:value 형태로 구성됨
header도 크게 3가지로 구분됨. general headers, request headers, entity headers)Host: google.com
Accept: text/html
Accept-Encoding: gzip,deflate
Connection: keep-alive
...
1)Host: 요청하려는 서버 호스트 이름과 포트번호
2)User-agent: 클라이언트 프로그램 정보. 이 정보를 통해 서버는 클라이언트 프로그램(브라우저)에 맞는 최적의 데이터를 보내줄 수 있음
3)Referer: 바로 직전에 머물렀던 웹 링크 주소
4)Accept: 클라이언트가 처리 가능한 미디어 타입 종류 나열
5)If-modified-Since: 여기에 쓰여진 시간 이후로 변경된 리소스 취득. 페이지가 수정되었으면 최신 페이지로 교체.
6)Authorization: 인증 토큰을 서버로 보낼 때 쓰이는 Header
7)Origin: 서버로 Post요청을 보낼 때 요청이 어느 주소에 시작되었는지 나타내는 값. 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing)에러가 발생함.
참고하면 좋은 자료:
https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏?category=889117
https://inpa.tistory.com/entry/AXIOS-📚-CORS-쿠키-전송withCredentials-옵션
8)Cookie: 쿠키 값이 key-value로 표현됨
- body
HTTP Request가 전송하는 데이터를 담고 있는 부분
전송하는 데이터가 없다면 body 부분은 비어있음
보통 post 요청인 경우, HTML 폼 데이터가 포함됨POST /test HTTP/1.1 Accept: application/json Accept-Encoding: gzip, deflate Connection: keep-alive Content-Length:83 Content-Type: application/json Host: google.com User-Agent: HTTPie/0.9.3 { "test_id" : "tmp_12345", "order_id: "8237352" }
Response Message
HTTP Response Message도 request와 동일하게 공백 제외하고 3부분으로 나눠진다.
Status Line
Headers
Body
-
Status line
HTTP Response의 상태를 간략하게 나타내주는 부분으로 3가지 부분으로 구성됨HTTP version, Status Code, Status Text
Http/1.1 200 OK
[HTTP version][Status Code][Status Text]-
headers
Request의 headers와 동일함
다만 response에서만 사용되는 header 값들이 있음.
ex. User-Agent 대신에 Server 헤더가 사용됨. -
body
Request의 body와 일반적으로 동일함
데이터를 전송할 필요가 없을 경우 body가 비어있게 된다.
http와 https의 차이점
: HTTP는 암호화되지 않은 데이터를 전송함. 즉, 브라우저에서 전송된 정보를 제 3자가 가로채고 읽을 수 있다.
HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합함
HTTPS 웹사이트는 독립된 인증 기관에서 SSL/TLS 인증서를 획득해야 함. HTTPS 웹사이트는 신뢰 구축을 위해 데이터를 교환하기 전에 브라우저와 인증서를 공유함. SSL 인증서는 암호화 정보도 포함하므로 서버와 웹 브라우저는 암호화된 데이터나 스크램블 된 데이터를 교환할 수 있다.
HTTP의 버전
-HTTP/1.1이 최초의 HTTP버전. HTTP/2와 HTTP/3은 프로토콜 자체를 업그레이드한 버전. HTTP/2는 텍스트 형식 대신, 바이너리로 데이터를 교환함. 또, 서버가 새 HTTP요청을 기다리는 대신, 클라이언트 캐시에 응답을 사전 전송할 수 있다. HTTP/3은 실시간 스트리밍 및 기타 최신 데이터 전송 요구 사항을 보다 효율적으로 지원하는 목적을 가진 버전.
HTTPS는 HTTP에서 데이터 보안 문제를 우선시함. 최신 시스템은 SSL/TLS와 함께 HTTP/2를 HTTPS로 사용함. 브라우저는 브라우저 주소 표시줄에서 웹 사이트 URL 옆에 있는 자물쇠 아이콘을 배치하여 사용자에게 HTTPS 연결을 표시함
보안적 장점 외에도 HTTPS는 HTTP애플리케이션보다 로드 속도가 더 빠름. 참조 링크도 더 잘 추적함. 추천 트래픽(광고 또는 소셜 미디어 백링크와 같은 서드 파티 소스에서 생성되는 웹 사이트 트래픽)소스도 더 정확하게 식별할 수 있음.
+HTTPS 설정 비용은 다 유료인가?
->NO! 무료 SSL인증서를 획득할 수있는 많은 출처가 있음
ex. Amazon Web Services에서는 AWS Certificate Manager를 제공함.
http와 https 비교 표(출처: https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/)
cache: 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소. 캐시는 저장공간이 작고 비용이 비싼 대신 빠른 성능을 제공함
캐시를 사용하면 좋은 경우
-접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우(서버의 균일한 API 데이터)
-반복적으로 동일한 결과를 돌려주는 경우(이미지나 썸네일)
장점: Cache에 데이터를 미리 복사하면 계산이나 접근 시간 없이 더 빠른 속도로 데이터 접근 가능. Enterprise급 애플리케이션에서는 반복적으로 데이터를 불러오는 경우, 지속적으로 DBMS 혹은 서버에 요청하는게 아니라 Memory에 데이터를 저장했다가 불러다 쓸 수 있어서 캐시를 사용하고 있음.
*Cache Hit와 Cache Miss
원하는 데이터가 캐시에 존재할 경우 해당 데이터를 반환하며, 이러한 상황을 Cache Hit라고 한다.
하지만 원하는 데이터가 캐시에 존재하지 않을 경우 DBMS 또는 서버에 요청을 해야하며 이를 Cache Miss라고 한다.
Cache-Control
: Cache-Control은 HTTP에서 캐시 메커니즘을 지정하기 위해 사용되는 헤더이다. 많은 디렉티브가 있지만, max-age 라는 디렉티브를 사용하면 캐시의 최대 수명을 설정할 수 있다. max-age의 단위는 초이다.
Http/1.1 200 OK
Content-Type: Text/html
Cache-Control: max-age=3600
Content-Length: 157웹 브라우저가 특정 리소스에 최초로 요청한 경우 서버는 Cache-Control 헤더가 포함된 응답을 보냄. 위의 응답을 받은 웹 브라우저는 응답 결과를 3600초, 1시간 동안 캐시에 저장함.
이후 웹 브라우저가 같은 리소스에 요청을 보낼 시, 실제 웹서버가 아닌 캐시에 저장한 사본 데이터를 사용자에게 제공함.
max-age 디렉티브에 명시한 캐시 유효 시간이 지난 이후 동일 리소스를 요청하면, 그땐 다시 실제 웹 서버에 리소스를 요청함. 이 때, 캐시된 데이터가 유효 시간을 아직 넘기지 않은 경우 신선하다(fresh)라고 표현하며, 캐시시간이 초과된 경우는 신선하지 않다(stale)라고 표현함.
pragma
서버가 캐싱을 처리하는 방식을 제어하는데 사용되는 HTTP/1.0 헤더.
사용 중단된 기능이며, 이 헤더는 Cache-Control HTTP/1.1 헤더가 없는 HTTP/1.0 캐시와의 하위 호환성을 위해 사용됨
문법: pragma: no-cache
Cache-Control:no-cache와 동일함.
cookie와 session
1.cookie
쿠키는 HTTP 통신을 기반으로 하며 브라우저에서 돌아가는 웹사이트나 웹애플리케이션에서 널리 사용됨.
한마디로 정의하면 서버가 어떤 데이터를 브라우저 측에 저장한 후 다시 그 데이터를 받아오는 기술 또는 그 데이터 자체를 뜻함. 이 때 쿠키의 제대로된 작동을 위해서는 브라우저의 역할이 제일 중요함.
쿠키의 매커니즘: 쿠키 데이터의 모양을 보면 <이름>=<값> 형태를 지니는 문자열임을 볼 수 있음. 서버와 브라우저는 기본적으로 HTTP 메시지 안에 쿠키를 담아서 주고 받음.
클라이언트 서버 모델에서는 서버가 클라이언트의 요청없이 클라이언트로 데이터를 보낼 수 없다. 따라서 이런 쿠키 전달 과정은 서버가 클라이언트 요청에 응답할 때 일어나게 됨. 하나의 Set-Cookie 응답 헤더에는 하나의 쿠키만 담을 수 있어서 여러개의 쿠키를 보낼 땐 아래와 같은 모습이 됨.
Set-Cookie: <이름>=<값>
Set-Cookie: <이름>=<값>
Set-Cookie: <이름>=<값>
서버로 부터 쿠키를 응답받은 브라우저는 해당 쿠키를 클라이언트 컴퓨터의 하드디스크에 저장함. 그리고 브라우저가 동일 서버에 요청을 하면 저장한 쿠키를 Cookie라는 요청 헤더에 실어서 돌려 보냄.
Cookie 요청 헤더에서 여러개의 쿠키를 나열할 때는 ;로구분함
Cookie: <이름>=<값>;<이름>=<값>;<이름>=<값>
서버는 일회성 작업으로 Set-Cookie 헤더를 통해 브라우저로 쿠키를 보내지만, 브라우저가 Cookie 헤더를 통해 서버로 쿠키를 돌려 보내는 것은 일정 시간동안 반복해서 수행되는 작업임.
쿠키는 유효기간이 별도로 명시되지 않으면 세션이 종료될 때 함께 만료됨. 반면, 유효기간이 명시되어있는 영속 쿠키는 특정 기간이나 특정 시점까지 유효함.
명시 방법은 Set-Cookie 응답 헤더에 Expires 속성이나 Max-Age 속성을 사용하면 됨
Set-Cookie: <쿠키 이름>=<쿠키 값>; Expires=종료 시점
Set-Cookie: <쿠키 이름>=<쿠키 값>; Max-Age=유효기간
쿠키의 한계
1)쿠키는 유실되기 쉽다
2)쿠키는 변조되기 쉽다
3)쿠키는 도난되기 쉽다
그럼에도 쿠키를 사용하는 이유
1)쿠키는 대규모 서비스에서 사용자 기반으로 부하분산(load balancing)이 필요할 때 큰 역할을 함.
쿠키를 활용하면 어렵지 않게 사용자를 고려하여 부하 분산을 할 수 있음.
-자세한 건 본 글의 쿠키에 대한 출처 중 하나인 https://www.daleseo.com/http-session/ 에 나옴.
2)쿠키와 세션은 상호 보완을 함
쿠키의 단점은 브라우저에 저장하기 때문에 유실/변조/도난되기 쉽다.
세션은 이에 비해 서버 측에서 관리 되기 때문에 위와 같은 위험이 적다.
그런데 세션은 서버당 하나만 유지할 수 있고 브라우저가 종료되면 세션데이터가 날아간다는 단점이 있다. 쿠키는 이 단점을 보완해준다.
서버에서 세션을 생성하면 그 세션을 식별할 수 있는 식별자 세션아이디를 얻는데 이 세션 아이디를 쿠키로 브라우저에 응답해주면 브라우저는 매번 요청을 보낼 때마다 세션아이디가 담긴 쿠키를 서버로 돌려보내게 됨. 서버에서는 이 세션 아이디에 해당하는 세션이 존재하는지만 확인해주면 됨.
HTTP 응답
HTTP/1.1 302 Found
Content-Type: text/html
Location: https://www.test.com/
Set-Cookie: SessionId=a3ee77w34e2
HTTP요청
GET/HTTP/1.1
Host: www.test.com
Cookie: sessionId=a3ee77w34e2
*세션 개념설명
일정 시간(방분자가 웹브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점)동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술.
특징
1. 웹 서버에 컨테이너의 상태를 유지하기 위한 정보를 저장함
2. 웹서버에 저장되는 쿠키
3. 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 보안이 좋다
4. 저장 데이터에 제한이 없음
5. 각 클라언트 고유 SessionID를 부여함. Session ID로 클라이언트를 구분해 각 클라언트 요구에 맞는 서비스 제공
*세션과 쿠키 비교(출처: https://velog.io/@seunghwa17/Session과-Cookie의-차이)
web storage
: 웹 스토리지는 서버가 아닌, 클라이언트에 데이터를 저장할 수 있도록 지원하는 HTML5의 새로운 기능. 쿠키는 약 4kb까지 밖에 저장 공간을 이용하지 못하는 반면 웹 스토리지는 약 5MB까지 저장공간을 이용할 수 있다.
주의점은 문자형 데이터 타입만 지원한다는 것이다.
웹 스토리지는 로컬 스토리지와 세션 스토리지가 있음
1)로컬스토리지
: 로컬 스토리지는 브라우저에 반영구적으로 데이터를 저장하며, 브라우저를 종료해도 데이터가 유지됨. 그런데 도메인이 다른 경우에는 로컬 스토리지에 접근할 수 없음
사용법: key와 value 저장
localStorage.setItem(key,value);
사용예시
localStorage.setItem('item1',10);
localStorage.setItem('item2','new item');
localStorage.setItem('item3',0.543534);
//불러올 때
localStorage.getItem('item1');
//키의 데이터를 삭제할 때
localStorage.removeItem('item1');
//모든 키의 데이터 삭제
localStorage.clear();2)세션 스토리지
세션 스토리지는 각 세션마다 데이터가 개별적으로 저장됨. 브라우저에서 여러개의 탭을 실행하면 탭마다 개별적으로 데이터가 저장되는 것을 볼 수 있다. 로컬스토리지와의 차이점은 세션스토리지는 세션을 종료하면 데이터가 자동으로 제거되면, 같은 도메인이라도 세션이 다르면 데이터에 접근할 수 없다는 것이다.
사용법 : key와 value 저장
sessionStorage.setItem(key,value)
sessionStorage.setItem("key1",10);
var n = sessionStorage.getItem("key1");proxy 서버
1)개념
컴퓨터 네트워크에서 다른 서버 상의 자원을 찾는 클라이언트로부터 요청을 받아 중계하는 서버. 대부분의 프록시는 웹 프록시를 말함. 컴퓨터 네트워크에서 다른 서버로의 자원 요청을 중계하며 분산 시스템 구조를 단순화하여 서비스의 복잡도를 줄일 수 있음.
2)사용목적
(1)익명으로 컴퓨터를 유지할 수 있다.
(2)네트워크 서비스나 콘텐츠로의 접근 정책을 적용하기 위해서 사용(ex. 원치 않는 사이트 차단)
(3)보안 및 통제를 뚫고 나가기 위해 사용할 수 있다. 역으로 IP추적을 당하지 않을 목적으로 사용한다.
(4)캐시를 사용하여 리소스로의 접근을 빠르게 하기 위해. 웹 프록시는 웹 서버로부터 웹 페이지를 캐시로 저장하는데 흔히 쓰임
(5)전달에 앞서 악성 코드를 목적으로 전달된 콘텐츠를 검사하기 위함
(6)밖으로 나가는 콘텐츠를 검사하기 위함(데이터 유출 보호)
3)종류
(1)포워드 프록시
:프록시 서버가 클라언트와 원격 서버 사이의 네트워크 상 어디에든 위치할 수 있다. 클라이언트는 원격의 목적지 서버의 주소를 기반으로 자원을 요청하고 프록시 서버는 그 주소를 받아 목적지 서버에 연결을 하고 자원을 가져옴.
(2)리버스 프록시
:프록시 서버가 사설 네트워크 상의 서버들 바로 앞단의 프론트엔드에 위치하여 서버들을 제어하고 보호함. 클라이언트는 리버스 프록시 서버의 주소를 목적지 서버로 하여 데이터를 요청함.리버스 프록시는 보안이나 암호화를 위해서 사용되기도 하고, 뒷단의 서버들에 대한 요청을 로드밸런싱을 위해 사용되기도 함.
*로드밸런싱? 출처: https://www.daleseo.com/http-session/
수많은 사용자들로 부터 동시에 들어오는 요청을 처리하려면 일반적으로 여러 대의 서버를 운영할 수 밖에 없는데요. 이런 경우 서버 앞 단에 로드 밸런서(load balancer)를 두고 부하가 여러 대의 서버로 골고루 분산될 수 있도록 인프라를 구성합니다.
(3)오픈 프록시
: 모든 인터넷 사용자가 엑세스 할 수 있는 프록시 서버로 공개 프록시를 사용하면 자신의 IP주소를 남기지 않고 익명으로 활동할 수 있다.
Developer tools> Network
:Chrome DevTool의 Network tab은 리소스가 올바르게 업로드/다운로드가 되었는지 확인이 필요할 때, 리소스의 HTTP header, 사이즈 등등의 부가적인 metadata를 검사할 때 대표적으로 사용된다.
Tip 1
더많은 정보 표시
: 네트워크 로그 테이블을 우 클릭하고 숨겨져있는데 필요한 정보칸예를 들어 Domain, Connection ID, Path 등을 선택할 수 있음
Tip 2
느린 네트워크 상황 시뮬레이션
: 의도적으로 네트워크 상황을 느리게 하여 느린 네트워크 환경에 있는 유저들의 유저경험을 간접적으로 체험/확인할 수 있다.
Tip3
HAR File: 네트워크로그를 파일형태로 import/export
HAR 파일은 HTTP 문서의 약자로 웹 사이트의 트래킹 정보에 대해 담고 있는 파일이다. HAR파일은 프론트엔드 개발자가 백엔드 개발자와 대화할 때 가장 유용하게 쓰인다.
Tip4
페이지 로딩시 로그기록 저장
f5 눌러서 refresh 해도 로그기록이 날라가지 않게 하려면 preserve log체크박스를 누르면 된다.
Tip 5
XHR비동기 Request 다시 보내기
:Request 기록 테이블에서 해당 XHR request를 우-클릭해서 XHR 비동기 request를 다시 보낼 수 있다.
TIP 6 커스텀 정보칸 표시
Request 테이블의 머릿말을 우클릭 하여 Response Headers>Manager Header Columns 을 선택하면 커스텀 정보칸을 표시할 수 있다.
tip 7
캐시 로딩
: devtool을 연상태에서 reload 아이콘을 1초~2초간 누르고 있으면 3가지 로딩 옵션이 가능함. 일반로딩과 하드로딩의 차이점은 캐시의 사용유무에 있음
일반적으로 F5 누른 로딩이 일반로딩, 자바스크립트 파일, 이미지, 텍스트 등의 resource 등의 캐시 없이 매번 다시 다운로드를 하는게 하드로딩
이는 유저의 초반 렌더링 속도를 확인하는데 유용하다.
wireshark
-나중에 알아볼 예정
출처:
1. http요약 https://hahahoho5915.tistory.com/62
2. http와 https 차이점 https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/
3.Cache란? https://mangkyu.tistory.com/69
4. Http 캐시(Cache-Control,유효성 검증 및 조건부 요청 등)
https://hudi.blog/http-cache/
5. pragma
https://runebook.dev/ko/docs/http/headers/pragma
6. 쿠키 1부: HTTP로 설명하는 쿠키(cookie)
https://www.daleseo.com/http-cookies/
7.쿠키 2부: 세션은 쿠키가 필요해~
https://www.daleseo.com/http-session/
8. Session과 Cookie의 차이
https://velog.io/@seunghwa17/Session과-Cookie의-차이
9.웹 스토리지 (Web Storage)의 특성과 사용법
https://untitledtblog.tistory.com/47
10. 웹 스토리지 사용법
https://www.daleseo.com/js-web-storage/
11.세션 스토리지 알고 사용하기
https://sub0709.tistory.com/55
12. 프록시 서버와 사용목적
https://dany-it.tistory.com/107
13. 프록시서버
https://ko.wikipedia.org/wiki/프록시_서버
14. 네트워크 탭을 효율적으로 사용하기 위한 7가지팁
https://medium.com/내일의-웹-개발/google-chrome-devtool-네트워크-탭을-효율적으로-사용하기-위한-7가지-팁-8d3166c5e273
