고정 헤더 영역
상세 컨텐츠
본문
HTTP 버전에 따른 비교를 해봤음.
HTTP1.0 vs HTTP1.1 vs HTTP2.0 vs HTTPS vs HTTP3.0
우선 HTTP1.0 vs HTTP1.1
HTTP1.0은 제일 먼저 상용화되면서 사용된 HTTP 버전이다.
HTTP 1.0 과 1.1의 가장 큰 차이점은 연결의 지속성임. HTTP는 기본적으로 TCP를 이용해서 통신하는데, 이 때 1.0은 TCP세션을 유지하지 않고, 1.1은 TCP세션을 유지함. 유지를 했을 때 이점은 TCP 여닫는 시간이 줄어들기 때문에 요청 응답도 빠르고 부하도 줄일 수 있음.
추가적인 정보로는
1. Pipelining(파이프라이닝) = 비동기라고 생각하시면 될 것 같습니다. HTTP1.0은 파이프라이닝을 제공하지 않기 때문에 1번 요청을 보내고 1번 응답을 받아야지 2번 요청을 보내는 식으로 동작하지만 / HTTP1.1은 여러개의 요청을 동시에 보낼 수 있습니다.
2. Host Header = HTTP1.0같은 경우 하나의 IP주소에 여러개의 도메인을 운영할 수 없습니다. 따라서 도메인 별로 IP를 구분해서 준비해야 하기 때문에 서버의 개수가 늘어납니다. 하지만 HTTP1.1은 가상호스팅이 가능해져서 IP하나에 여러개의 도메인을 적용시킬 수 있습니다.
3. 인증절차의 향상 = HTTP1.1은 header에 proxy-authentication , proxy-authorization 두 개의 header가 추가됩니다. 따라서 프록시가 사용자의 인증을 요구하는게 가능해졌고, 이를 통해 인증절차가 향상되었습니다.
HTTP1.1 vs HTTP2.0
HTTP1.1 과 HTTP2.0 의 가장 큰 차이점은 속도이다.
HTTP2.0은 헤더를 압축해서 보낼 수 있고, 한번의 연결로 동시에 에러메세지도 주고 받을 수 있음.
간략하게 말하자면, HTTP1.1을 프로토콜의 성능에 초점을 맞춰 수정한 버전이 HTTP2.0 임.
HTTPS
HTTP + SSL(TLS)임.
HTTPS는 하이퍼 텍스트 전송 프로토콜 보안으로 표준 HTTP와 동일한 방식으로 작동함.
서버와 주고받는 데이터가 암호화되기 때문에 웹사이트에 추가적인 보호를 제공.
즉, 개인 데이터를 훔치거나, 해킹하거나 볼 수 없도록 작동함.
http의 문제는 서버가 브라우저로 보내는 정보가 암호화되지 않는다는 점인데, 이 문제를 TLS/SSL로 해결하는 것.
TLS 프로토콜 사용으로 데이터 무결성을 제공하며, 사용자가 의도한 사이트와 통신하고 있음을 보장받을 수 있다.
SSL인증서를 통한 정보 암호화를 통하여 해커가 중간에 가로채더라도 데이터 원본이 아닌 암호화된 데이터를 보게 되는 것.
HTTP3.0
한 줄 요약하면 HTTP3.0은 HTTP의 주요 개정 버전으로 UDP기반의 QUIC프로토콜을 사용하여 통신함. 이다.근데 신기한 기술이라서 좀 추가적으로 찾아봤음. 스터디 팀원들에게 전달하기 위해 작성했던 것 가져옴.
좀 많은 내용이 들어가야 할 것 같은데 요약해서 말하면, 왼쪽에서 설명한 것 처럼 HTTP3.0은 UDP를 사용합니다. TCP와 UDP의 차이를 아시는 것처럼 TCP는 신뢰성과 느린속도, UDP는 낮은 신뢰성과 빠른속도를 제공합니다. 신뢰성이란 단어의 의미는 전송되는 패킷의 순서, 패킷 유실 여부 등을 검사해서 송신 측이 보낸 모든 데이터가 수신 측에 온전히 전달되는가를 말합니다. 일단 UDP를 선택한 이유에 대해 설명하자면, TCP는 클라이언트와 서버간의 신뢰성있는 통신을 할 수 있도록 몇 가지 방법을 사용하죠? 이 때 레이턴시가 발생합니다. 그리고 이 레이턴시를 줄이기 위해서는 TCP에서 정의한 기능 외에도 많은 부분들을 건드려야 하는데, 제한 사항이 많습니다. 대역폭을 늘려도 언젠간 느려지겠죠? 전송 속도를 높혀도 빛의 속도보다 빠르게 전송할 수 없기 때문에 한계가 있습니다. 그래서 HTTP3.0 은 UDP 기반인 QUIC 프로토콜을 사용합니다. 위에서 언급한 제약 조건을 바로잡기 위해서는 프로토콜 자체를 손봐야한다는 결론이었던 거죠. TCP는 손보기 힘들기 때문에 UDP를 선택한 것입니다. 그럼 UDP를 사용한다 했는데 HTTP3.0은 신뢰성은 무시하고 있는가? 하면 아닙니다. UDP는 하얀 도화지 같은 프로토콜로 커스터마이징이 용이하다는 것입니다. 똑똑한 구글개발자님들께서 이쁘게 커스터마이징해주시겠죠. 그럼 UDP를 써서 좋은점을 정리해보면 1. 연결 설정 시 레이턴시가 감소합니다. TCP를 사용하지 않기 때문에 3 way handshake 과정을 거치지 않습니다. 2. 패킷 손실 감지에 걸리는 시간을 단축합니다. 3. 클라이언트의 IP가 바뀌어도 연결이 유지됩니다. TCP같은 경우는 소스의 IP 주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기 때문에 클라이언트의 IP가 바뀌는 상황에는 연결이 끊어집니다. 연결이 끊어지면 또 3 way handshake를 해야하는 눈물나는 상황이 발생합니다. 반면 QUIC은 connection ID를 사용하여 서버와 연결을 생성하기 때문에 클라이언트 IP가 바뀌어도 기존의 연결을 유지할 수 있습니다. 당장은 HTTP3.0을 상용화하긴 어렵지만 널리 사용되던 TCP가 아닌 UDP를 사용하는 새로운 시도라는 측면에서는 공부해볼만한 기술이라고 생각합니다.
list, tuple의 공통점
1. 둘 다 여러 데이터를 담을 수 있습니다.
list = [1,2,3,4,5]
tuple = (1,2,3,4,5)
2. 둘 다 인덱스를 통해 특정 요소에 접근할 수 있다.
list[0] , tuple[0]
3. 둘다 iterable하다. for문 가능
차이점
1. list는 mutable(가변)인데 tuple은 immutable(불변)이다.
list[0] = “hello” → list = [“hello”, 2, 3, 4, 5]
tuple[0] = “hello” → 오류발생
2. list는 딕셔너리의 key값으로 쓸 수 없고, tuple은 가능하다.
→ 딕셔너리의 key값은 불변한 값만 올 수 있기 때문.
→ 튜플에 리스트가 있으면 이 또한 key값 불가능
3. 객체를 복사했을 때의 identity 차이.
list는 list를 복사하고 is로 비교해보면 False가 뜸. 같은 객체가 아니라 새로운 객체가 생김.
tuple은 복사하고 is로 비교하면 True가 뜸. 복사된 변수가 원본과 같은 객체를 가르킴.
→ tuple은 불변변수이기 떄문에 하나를 바꿨을 때 반대편의 값도 바뀔 걱정 안해도됨
→ 객체를 굳이 복사하지 않고 기존의 객체에 변수만 할당하는 식으로 효율을 올림.
continue vs break vs pass
1. continue = 바로 다음 순번의 loop를 수행.
2. break = 반복문을 멈추고 loop 밖으로 나감.
3. pass = 실행할 코드가 없는 것으로 다음 행동을 계속해서 진행.
예시
1. continue
for i in range(10):
if i % 2 == 0:
continue
print(i)
print(i)
print(“Done”)
→ 결과
1
3
5
7
9
Done
i 가 2의 배수 인 경우 continue가 실행되는데, continue가 실행되면 해당부분을 그냥 넘어감.
해당 순번의 loop를 넘어가 다음번 loop가 돔. 따라서 2의 배수면 print(i)가 둘 다 실행 안되고 다음 loop로 넘어가는 것.
2. break
for i in range(10):
if i % 2 == 0:
break
print(i)
else:
print(i)
print(“Done”)
→ 결과
Done
break 가 실행되면 해당 반복문을 멈추고 밖으로 나감.
0부터 시작인데 0 % 2 == 0 → break 끝! print(“Done”) 실행
3. pass
for i in range(10):
if i % 2 == 0:
pass
print(i)
else:
print(i)
print(“Done”)
→결과
0
1
2
3
4
5
6
7
8
9
Done
결과를 보면 반복문 수행에 전혀 영향을 주지 않는 것을 볼 수 있음.
pass는
1. 조건문에 넣어줄 조건이 딱히 없을 때
2. class 선언할 때, 초기에 넣을 값이 없을 때 → 일단 코드 작성하고 해당 class에서 오류 발생을 막기 위함.
Django vs DRF
먼저 RESTful 에 대해서 알아야함.
Representational State Transfer의 줄임말로, http의 url과 http method(GET, POST, PUT, DELETE)를 사용해서 API 가독성을 높인 구조화된 시스템 아키텍쳐
Django도 View 클래스 자체가 RESTful 한 서버를 만들기에 최적화된 프레임워크이긴 함.
DRF란 그래서 Django 안에서 RESTful API 서버를 쉽게 구축할 수 있도록 도와주는 오픈소스 라이브러리이다.
Django는 Model ---> View ---> (queryset을 템플릿 언어로 랜더링) ---> Template
DRF 는 Model ---> (Serializer) ---> APIView --->(json을 템플릿언어로 랜더링) ---> Template
그래서 DRF를 쓰는 이유는?
1. Queryset data를 json 형태로 직렬화 시켜주는 Serializer를 제공해준다.
- 직렬화하는 이유?
- 사용하고 있는 데이터들을 파일 저장 혹은 데이터 통신에서 파싱 할 수 있는 유의미한 데이터를 만들기 위해서.
2. serializer에서 데이터의 유효성 검사도 해주기 때문에 개발 편의성이 증가함.
3. 웹브라우저 API는 범용성이 크기 때문에 개발을 편하게 해줌.
