github.com/baeharam/Must-Know-About-Frontend
baeharam/Must-Know-About-Frontend
:mortar_board: 취준생이라면 반드시 알아야 하는 프론트엔드 관련 지식들. Contribute to baeharam/Must-Know-About-Frontend development by creating an account on GitHub.
github.com
따라치면서 공부
TCP와 UDP
- OSI 7계층에서 전송계층에 속하는 데이터 전송 프로토콜
TCP
- 연결지향적이다. 2개의 호스트가 통신을 하기전에 연결이 반드시 이루어져야한다.
- 높은 신뢰성과 순서대로 전송하는 것을 보장한다.
- 흐름제어 : 송신자의 데이터 양을 조절
- 혼잡제어 : 네트워크 상황을 감지하고 송신자의 데이터 양을 조절
- 에러감지 : 잘못 전송된경우 재전송
- 전 이중 방식으로 두 호스트 모두 송신자와 수신자가 될 수 있다.
- 바이트 스트림을 사용하여 데이터를 연속적인 바이트로 보고, 세그먼트라는 단위의 패킷으로 쪼개서 보낸다.
- HTTP, FTP, SMTP, TELNET등에서 사용
UDP
- 비연결형으로 연결을 설정하고 해제하는 과정이 없다.
- 신뢰성이 없고 데이터의 순서를 보장하지 않는다.
- 패킷의 단위가 데이터그램으로 경계가 분명하여 수신자는 송신자가 보낸 그대로의 크기로 받게 된다.
HTTP
클라이언트 - 서버 모델을 따르는 프로토콜로 TCP/IP 위에서 동작하며 well-known 포트인 80번 포트를 사용하여 통신한다.
특징
- 비 연결 지향. 클라이언트가 서버에게 리소스를 요청한 후 응답을 받으면 연결을 끊어버리는 특징이 있다. 연결을 유지하게 되면 서버에 부담을 줄 수 있기 때문에 상당히 많은 클라이언트에게 요청을 받는 웹 서버의 경우 응답을 처리했으면 연결을 끊음으로 서버의 부담을 줄인다. 하지만 리소스를 요청할 때마다 연결해야 하는 오버헤드 비용이 발생한다. 요청 헤더의 Connection: keep-alive 속성으로 지속적 연결 상태를 유지할 수 있다. 요청을 할 때마다 연결하지 않고 기존의 연결을 재사용하는 방식임. HTTP 1.1 부턴 지속적 연결 상태가 기본이며 이를 해제하기 위해선 명시적으로 요청 헤더를 수정해야 한다.
- 무상태성 : 각각의 요청이 독립적으로 여겨지는 특징으로, 서버는 클라이언트의 상태를 유지하지 않는다. 즉 각 클라이언트에 맞게 리소스를 응답하는 것은 불가능하다. 이를 해결하기위해 쿠키나 세션 또는, 토큰 방식의 OAuth 및 JWT를 사용한다.
- Method - GET, POST, PUT, DELETE, PATCH
HTTPS
기존의 HTTP를 암호화한 프로토콜로 보안이 강화된 버전이다. TCP의 연결이 이루어진 후 TLS를 통해 암호화 설정이 되고 통신을 하는 방식이다.
동작 방식
1. 클라이언트가 서버에게 접속요청을 하면 서버는 CA에서 발급받은 인증서를 보낸다. 인증서에는 CA의 비밀키로 암호화된 사이트정보와 공개키가 들어있다.
2. 클라이언트는 인증서를 받아 CA의 공개키로 복호화하여 접속요청한 서버가 신뢰할만한지 검증한다.
3. 복호화가 되면 인증서가 신뢰할 만 하기 때문에 데이터를 주고받을 대칭키를 생성한다.
4. 대칭키를 서버의 공개키로 암호화하여 서버에게 전송한다.
5. 서버는 자신의 비밀키로 클라이언트가 보낸 대칭키를 복호화한 뒤 그 대칭키를 통해 데이터를 주고받는다.
HTTP/1.1과 HTTP/2의 차이점
2015부터 HTTP/1.1을 개선한 2가 등장함.
기존 1.1의 문제점
- HOLB(Head Of Line Blocking) : HTTP 요청을 할 때는 요청을 하고 나서 응답이 와야 다음 요청을 할 수 있었는데 HTTP/1.1에 들어오면서 파이프라이닝 기법을 통해 응답을 받지 않고도 여러개의 요청을 연속적으로 할 수 있게 되었다. 하지만 이 또한 처음의 요청에 대한 응답이 오래걸리는 경우, 그 다음 응답까지의 시간이 지연되는 현상이 발생한다. 이렇게 파이프라이닝 기법은 심각한 문제를 안고 있었으며 이를 HOLB라고 함.
- 무겁고 중복 많은 헤더 구조 : 요청을 할 때 요청헤더에 메타정보를 넣어서 보내게 되는데, 매 요청마다 보내는 정보가 많아져서 헤더가 무거워지고 쿠키 같은 경우는 계속 보내게 되기 때문에 중복도 많아지는 문제가 있다.
2의 개선방법
- 멀티플렉싱과 스트리밍 : HTTP 요청 데이터는 헤더와 본문으로 구성되는 이를 각각 프레임이라는 단위로 지정하고 스트림이라는 연결단위를 통해 헤더 프라임 혹은 본문 프레임을 보내도록 그 방식을 바꿨다. 하나의 스트림은 요청/응답으로 구성되고 여러개의 스트림을 생성할 수 있다. 바로 이것이 스트리밍을 통한 멀티플렉싱이다. 이를 통해 기존의 HTTP/1.1의 문제점인 HLOB를 해결할 수 있게 된다. 또한 요청한 리소스간의 우선순위를 설정하기 때문에 스트림 별로 가중치가 매겨지고 브라우저가 리소스들을 수신하는 순서를 적절하게 결정한다.
- 서버푸시 : 브라우저가 요청하지 않으면 서버는 응답하지 않는 것이 보통이지만, 요청한 HTML 문서에 리소스가 포함되어 있는 경우 서버가 브라우저에게 밀어주는 (push) 방식을 취하여 브라우저의 요청을 최소화시킨다.
- 헤더 압축 : 헤더 테이블을 사용하여 이전 헤더 정보를 유지하고 허프만 인코딩 기법으로 헤더를 압축해서 전송하여 중복과 크기를 줄인다.
URL과 URN을 포함하는 URI
- URI(Uniform Resource Identifier) : 통합 자원 식별자라는 의미로 인터넥 상의 리소스를 고유하게 식별할 수 있는 식별자. URI에는 위치를 알려주는 URL과 전 세계를 통틀어 고유한 이름을 의미하는 URN이 존재한다.
- URL(Uniform Resource Locator) : 해당 위치에서 어떻게 리소스를 얻어낼 것인가에 대한 정보. 특정 서버의 한 리소스에 대한 구체적인 위칠르 서술한다. 우리가 아는 http://naver.com이 URL에 해당한다.
- URN (Uniform Resource Name) : 리소스를 유일하고 영구적인 이름으로 식별하지만 인터넷상의 위치는 알려주지 않는다. 매번 바뀌는 위치가 아닌 유일한 식별자인 이름을 기준으로 자원을 식별하겠다는 의도. ex) run:isbn:0451450523 (책을 식별하는 isbn번호)
REST API
- REST : Representational State Transfer의 약자로 전반적인 웹 어플리케이션에서 상호작용하는데 사용되는 웹 아키텍쳐 모델이다. 즉, 자원을 주고받는 웹 상에서의 통신 체계에 있어서 범용적인 스타일을 규정한 아키텍처라고 할 수 있다.
- API : Application Programming Interface의 약자로 구글 맵 API, 카카오 비전 API등 기존에 있는 응용 프로그램을 통해서 데이터를 제공받거나 기능을 사용하고자 할 때 사용하는 인터페이스 및 규격을 말한다. API는 프로그래밍 언어, 운영체제 등에서도 사용되는 범용적인 용어이다. REST API라는 것은 REST한 원칙을 적용하여 서비스 API를 설계한 것을 말함. 대부분의 서비스가 REST API를 제공한다.
특징
1) 균등한 인터페이스 - REST가 HTTP의 표준만 따른다면 어떠한 기술이던지 접목하여 사용할 수 있기 때문에 플랫폼이나 언어의 제약에 구애받지 않는다. 요즘은 REST API를 정의할 때 JSON을 많이 쓰지만 XML을 적용할 수도 있다.
2) 무상태성 - 서버는 클라이언트의 상황을 고려하지 않고 APi요청에 대해서만 처리하기 때문에 상태가 없다고 표현한다. 클라이언트를 고려하지 않아도 되기 때문에 구현이 간결해진다.
3) 캐싱가능 - REST는 HTTP 표준을 기반으로 만들어졌기 때문에 HTTP의 특징인 캐싱을 사용할 수 있다. REST API를 활용하여 GET 메소드를 Last-Modified 값과 함께 보낼 경우, 컨텐츠의 변화가 없을 때 캐시된 값을 사용하게 된다. 이렇게 되면 네트워크 응답시간 뿐만 아니라 API 서버에 요청을 발생시키지 않기 때문에 부담이 덜 하다는 장점 또한 가지게 된다.
4) 자체 표현성 - REST API의 자원명시 규칙 및 메소드는 그 자체로 의미를 지니기 때문에 어떠한 요청에 있어서 그 요청 자체로 어떤 것을 표현하는지 알아보기 쉽다.
5) 클라이언트-서버 구조 - REST 서버가 API를 제공하는 방식이기 때문에 클라이언트에서 처리하는 부분과 독립적으로 동작한다. 따라서, 서로간의 의존성이 줄어들고 클라이언트와 서버를 최대한 독립적으로 개발할 수 있도록 도와준다.
6) 계층형 구조 - 클라이언트는 계층형 구조가 불가능하지만 REST 서버의 경우, 보안/로드 밸런싱/암호화 등을 추가할 수 있고 Proxy 및 게이트웨이 등의 중간매체를 사용할 수 있다.
- REST 규칙 - URI는 리소스를 표현하고, 그 리소스에 대한 행위는 HTTP의 Method로 표현해야한다.
쿠키 vs 세션
- 쿠키 : 쿠키란 클라이언트의 웹 브라우저에 저장되는 작은 데이터 조각으로 서버가 클라이언트의 요청을 식별하는데 사용된다. 쿠키를 활용해서 사용자를 구분하는게 매우 유용하지만, 클라이언트가 수정할 수도 있고 해커가 탈취할 수도 있기 때문에 보안에 취약하다. 따라서 아이디와 비밀번호 같은 민감한 정보 보단 세션 ID 관리, 개인화(사용자 선호 테마 등), 트래킹(사용자 행동 기록 및 분석) 등의 목적으로 사용한다.
- 세션 : 세션이란 브라우저가 서버에 연결되어 있는 동안 유지하는 데이터 집합이다. 사용자가 웹 사이트에 방문하여 서버에 요청을 보내게 되면, 사용자의 정보를 서버에 저장하고 그 정보를 식별할 수 있는 세션ID를 Set-Cookie 헤더로 클라이언트에게 전송한다. 위에서 말했던것처럼 클라이언트는 쿠키로 세션 ID를 관리하고 해당 서버에 요청할 때 마다 Cookie 헤더에 세션 ID를 포함시켜 전송하기 때문에 서버는 클라이언트를 식별하여 그에 맞는 정보를 응답으로 줄 수 있게 된다. 따라서 민감한 정보 관리(사용자 비밀번호 및 개인정보)의 목적으로 사용한다고 볼 수 있다.
- 차이점
- 쿠키
- 클라이언트 쪽에 저장한다.
- 브라우저가 꺼져도 삭제되지 않고 사용자가 삭제하거나 정해진 시간만큼 유지된다.
- 문자열만 저장할 수 있다.
- 클라이언트에서 보내기 때문에 속도가 빠르다.
- 민감한 데이터를 스니핑 당할수도 있기 때문에 보안에 취약하다.
- 세션
- 서버쪽에 저장한다.
- 브라우저가 꺼질 경우 삭제된다.
- 문자열 뿐 아니라 객체도 저장할 수 있다.
- 서버쪽에서 처리하기 때문에 속도가 비교적 느리다.
- 서버에서 민감한 데이터를 갖고 있기 때문에 비교적 보안이 좋다.
URL을 입력하고 벌어지는 일
- URL을 브라우저의 주소창에 입력
- 브라우저가 URL을 해석하고, 문법에 맞지 않으면 기본 검색엔진으로 검색한다
- 문법에 맞으면 URL의 호스트 부분을 인코딩한다.
- HSTS(HTTP Strict Transport Security) 목록을 확인하고 있으면 HTTPS로, 없으면 HTTP로 요청한다.
- DNS(Doman Name Server) 조회
- 브라우저 / 로컬 캐시 확인해서 도메인이 해당하는 IP가 있는지 확인한다.
- 없으면 OS에게 DNS 서버에 요청하라고 지시한다.
- DNS 서버는 해당 도메인에 해당하는 IP를 돌려준다.
- TCP 소켓을 열고 3-way handshake로 연결을 설정한다.
- HTTPS 요청이라면 TLS(Transport Layer Security) hanshake 과정을 통해 세션키를 생성한다.
- 세션이 유지되는 동안 서버에게 요청하고 응답을 받는 과정을 반복한다.
- 웹 브라우저는 응답받은 HTML/CSS/JS 및 이미지, 폰트 등의 리소스를 사용하여 렌더링한다.
- 서버와의 세션이 종료되면 4-way handshake로 연결을 종료한다.
CDN
- 정의 : CDN은 컨텐츠 전달 네트워크의 약자로 말 그대로, 컨텐츠를 전달하는 네트워크를 구성하는 것이다. 보통 웹사이트를 로딩할 때는 웹 서버에 HTTP 요청을 하여 리소스를 가져오지만 웹서버가 아니라 현재 사용자가 접속한 위치에서 가장 가까운 서버에 리소스를 캐싱해놓고 보다 빠르게 가져오는 기법이다. 물론, CDN 네트워크를 구축하기 위해선 해당 지역의 ISP, 네트워크 사업자, 이동통신 사업자에게 서버의 호스팅 비용을 지불해야한다. 이렇게 네트워크를 구축하게 되면 정적 리소스를 더욱 빠른 속도로 서비스할 수 있다.
- 장점 : 리소스를 캐싱해놓기 때문에 로딩속도가 빨라진다 / 1개의 웹서버에서만 리소스를 가져오지 않기 때문에 서버의 부하가 줄어든다 / 보통 1개의 도메인이 10개의 병렬연결을 허용하는데 CDN을 사용하면 병렬연결이 늘어난다.(?? 잘모르겠음)
(big-blog.tistory.com/676) 브라우저마다 한번에 동시에 요청할 수 있는 HTTP요청의 제한이 있다고 한다. ConenctionsPerHostname은 한 호스트에 동시에 요청할 수 있는 최대 요청의 제한이고 MaxConnections는 모든 호스트에 동시에 요청할 수 있는 횟수의 제한이다.
위의 병렬연결은 CDN을 활용한다면 전자인 ConnectionsPerHostname에 대한 제한을 어느정도 회피가능하다는 이야기인듯.
- 단점 : 서버를 구축하는 비용이 더 많이나감 / 사용자가 해당하는 CDN을 막아놓으면 리소스 로딩이 막힌다. / 자신의 나라에 CDN 서비스 회사의 서버가 없어 해외 CDN서버를 사용하는 경우 더 느려질 수 있다.
