[프론트엔드 면접 준비] Browser 질문 목록 (feat. HTTP, TCP/UDP)

Rachel·2024년 8월 8일

프론트엔드 면접 준비

목록 보기

2/4

실제 면접에서 받은 질문들 앞에는 ⭐️ 별을 붙였습니다.

브라우저 렌더링 과정 설명해주세요.

브라우저가 화면에 나타내는 요소를 렌더링할 때, 웹킷이나 게코 등과 같은 각 브라우저 렌더링 엔진을 사용합니다. 렌더링 엔진이 HTML, CSS, JS로 렌더링시 CRP(Critical Rendering Path)라는 프로세스를 사용하며 다음 단계로 이루어집니다.

첫 번째로, HTML를 파싱 후, DOM 트리를 구축합니다.
두 번째로, CSS를 파싱 후, CSSOM 트리를 구축합니다.
세 번째로, JS를 실행합니다 (HTML 중간에 스크립트가 있다면 해당 스크립트의 실행이 완료될때까지 HTML 파싱이 중단됩니다. 이를 피하고 싶다면 제거하거나 async, defer 속성을 이용할 수 있습니다)
네 번째로, DOM과 CSSOM를 조합하여 렌더트리를 구축합니다.
(이때, display: none 속성과 같이 화면에 보이지도 않고 공간도 차지하지 않는 것은 렌더 트리로 구축되지 않음)
다음으로, 뷰포트를 기반으로 렌더트리의 각 노드가 가지는 정확한 위치와 크기를 계산합니다. (Layout)

마지막으로, 계산한 위치/크기를 기반으로 화면에 그립니다. (Paint 단계)

✏️ 용어 정리
CRP : HTML, CSS, JS를 화면에 픽셀로 변화시키는 일련의 단계

파싱: 하나의 프로그램을 런타임 환경이 실제로 실행할 수 있는 내부 포맷으로 분석하고 변환하는 것. 문서의 내용을 토큰으로 분석하고, 문법적 의미와 구조를 반영한 parse tree를 생성한다.

뷰포트(viewport): 웹 페이지를 볼 때 보이는 영역

Reflow, Repaint 되는 시점

Layout = Reflow: 생성된 DOM 노드의 레이아웃 수치(너비, 높이, 위치 등) 변경 시 영향 받은 모든 노드의 (자신, 자식, 부모, 조상(결국 모든 노드)) 수치를 다시 계산하여(Recalculate), 렌더 트리를 재생성하는 과정

DOM 요소 추가, 제거 또는 변경
CSS 스타일 추가, 제거, 변경
CSS 클래스 추가
CSS 애니메이션, 트랜지션, 애니메이션의 모든 프레임에서 리플로우 발생
offsetWidth 와 offsetHeight 의 사용. offsetWidth 와 offsetHeight 속성을 읽으면, 초기 리플로우가 트리거되어 수치가 계산
유저 인터랙션으로 인한 hover, 필드의 텍스트 입력, 창 크기 조절, 글꼴 크기 변경, 스타일시트 또는 글꼴 전환 등

Repaint: Reflow 과정이 끝난 후 재 생성된 렌더 트리를 다시 그리는 과정

가시성이 변경되는 순간(opacity, background, visibility, outline)
리플로우가 실행된 순간 뒤에 실행

✏️ 용어 정리
offsetWidth: 요소의 너비를 반환. 보더(border), 수직 패딩(vertical padding), 수직 스크롤바(만약 존재한다면), 수직 마진(vertical margin)을 포함
offsetHeight: 요소의 높이를 반환. 보더(border), 수평 패딩(horizontal padding), 수평 스크롤바(만약 존재한다면), 수평 마진(horizontal margin)을 포함 (가시 영역 포함)
렌더링된 요소의 크기를 기준으로 계산. 읽기 전용 속성.

Reflow, Repaint 모두 발생하지 않는 속성?

cursor, orphans, perspective는 Reflow, Repaint가 발생하지 않습니다.

transform, opacity는 Reflow를 발생시키지 않고 Repaint만 발생시킵니다.

✏️ 용어 정리
orphans: 페이지나 컨테이너의 맨 아래에 있는 텍스트 블록의 최소 줄 수를 설정
perspective: 3D 공간에서 요소를 바라보는 관점을 설정. 요소 자체가 아닌 요소의 자식 요소에 적용되는 3D 변환에 영향을 준다.
transform: 요소에 2D 또는 3D 변환을 적용. 변환에는 회전, 크기 조절, 기울이기, 이동 등이 포함.

google에 https://www.google.com을 검색하면 일어나는 일

사용자가 웹 브라우저를 통해 https://www.google.com을 입력하면 IP 주소값을 찾기 위해 캐싱된 DNS 기록이 있는지 확인합니다. 캐시된 데이터가 없다면 URL 주소 중 도메인 네임(google.com) 부분을 DNS(도메인 이름 시스템) 서버에서 재귀적으로 검색합니다.
DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소(예: 192.0.2.44)를 찾으면 사용자가 입력한 URL 정보와 함께 전달합니다.
브라우저는 HTTP 프로토콜을 사용하여 요청 메시지를 생성하고 HTTP 요청 메시지는 TCP/IP 프로토콜을 사용하여 서버로 전송됩니다.
서버는 response 메시지를 생성하여 다시 브라우저에게 데이터를 전송합니다.
브라우저는 response를 받아 파싱하여 화면에 렌더링합니다.

✏️ 용어 정리
DNS: 도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com )을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환합니다. 모든 통신에는 주소가 필요합니다. 출발지와 도착지의 주소를 알아야 통신을 할 수 있습니다. 우리는 이 주소를 IP라고 부릅니다. IP 주소로 변환하는 과정에 개입하는 것이 DNS 입니다.

URL: URL(Uniform Resource Locator)은 통합 자원 지시자로 인터넷의 리소스를 가리키는 표준 명칭으로 서버의 자원을 요청할 때 사용됩니다. URL을 통해 인터넷 상의 모든 리소스를 요청할 수 있으며, HTTP, FTP 등의 자원 요청도 가능합니다.

프로토콜: 프로토콜은 통신하기 위한 약속들을 기술적으로 잘 정의해 둔 것입니다. 데이터를 송수신하는 순서와 내용을 결정합니다. HTTP, TCP/IP, UDP 모두 프로토콜입니다.

프로토콜 스위트: 네트워크 통신에서 여러개 프로토콜이 모여 하나의 집합을 이루는 것을 의미함

IP: IP (Internet Protocol)은 비신뢰성, 비연결지향 데이터그램 프로토콜로 패킷을 받아서 주소를 해석하고 경로를 결정하여 다음 호스트로 전송하는 역할을 합니다.

response: HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식입니다. 메시지 타입은 두 가지가 있습니다. 요청(request)은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지고, 응답(response)은 요청에 대한 서버의 답변입니다.

TCP/IP란?

TCP/IP는 프로토콜 스위트로, TCP(Transmission Control Protocol)와 IP(Internet Protocol)를 합쳐서 부르는 말입니다. 송신자가 수신자에게 IP 주소를 사용해서 데이터를 전달할 때, IP는 데이터의 전달 경로를 결정하고, TCP는 데이터가 제대로 전달되었는지 확인하는 역할을 합니다.

TCP란?

TCP (전송 제어 프로토콜)은 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요한 네트워크 프로토콜입니다. TCP는 데이터 전송을 제어하고 데이터를 어떻게 보낼 지, 어떻게 맞출 지 정합니다. 또한 데이터와 패킷이 보내진 순서대로 전달하는 것을 보장해줍니다.신뢰성과 연결성을 책임지기 위한 프로토콜이 TCP입니다. 호스트와 호스트간의 데이터 전송은 IP(인터넷 계층 프로토콜)에 의지하면서 동시에 신뢰성 있는 전송에 대해서는 TCP가 책임지는 구조입니다.

TCP 연결시 3-wayhandshake로, 종료시 4-wayhandshake 사용으로 신뢰성과 연결성을 보장합니다.

TCP와 UDP의 차이는?

TCP와 UDP 두가지는 전송계층입니다. TCP는 연결형 프로토콜로 데이터 신뢰성과 순서를 보장하는 반면에,
UDP는 비연결형 프로토콜로 데이터 신뢰성을 체크하지 않기 때문에, 비교적 TCP보다 전송속도가 빠르다는 장점이 있습니다.

TCP와 UDP 각각의 적절한 사용처?

채팅 서버-클라이언트간에는 빠른 데이터 송신보다도 신뢰성 있는 데이터 송수신이 중요하기 때문에 TCP 프로토콜을 사용하는 것이 좋습니다.

실시간 스트리밍 서비스에서는 빠른 속도가 필요하고 신뢰성이 크게 중요하지 않기 때문에 UDP 프로토콜을 사용하는 것이 좋습니다.

DNS에서 TCP와 UDP중 뭘 사용하나요?

DNS는 UDP를 사용합니다. UDP를 사용하는 이유는 작은 쿼리와 응답이 빠른속도로 처리되어야 하기 때문입니다.

HTTP란?

HTTP(HyperText Transfer Protocol)은 TCP 기반의 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜입니다. HTTP는 Text Protocol로 사람이 쉽게 읽고 쓸 수 있습니다. 프로토콜 설계상 클라이언트가 요청을 보내면 반드시 응답을 받아야 합니다. 응답을 받아야 다음 request를 보낼 수 있습니다.

HTTP와 HTTPS 차이점은?

HTTP와 HTTPS는 보안적인 차이와 SEO차이가 있습니다.

보안적 차이
만일 HTTP의 클라이언트와 서버간에 데이터를 교환할때 원본 데이터를 주고 받기 때문에 해커에 의해서 가로채기 쉽습니다. 하지만, HTTPS는 네트워크로 전송되는 데이터를 암호화합니다. 때문에 해커가 데이터를 가로채도 암호화가 되어 있어서 어떤 내용인지 알기 어렵습니다.
SEO 차이
일반적으로 검색엔진은 HTTPS의 웹사이트의 신뢰성을 더 높게 산정합니다.

HTTPS는 HTTP 프로토콜로 송수신하는 일반 텍스트를 SSL 또는 TLS 프로토콜을 통해 암호화합니다.

REST란?

자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것입니다. HTTP URI를 통해 자원을 명시하고 HTTP 메서드(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것을 말합니다. 즉, 자원 기반의 구조 설계의 중심에 자원이 있고, HTTP 메서드를 통해 이를 처리합니다.

API란?

응용프로그램에서 사용할 수 있도록 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스입니다. 쉽게 말해 프로그램끼리 통신할 수 있도록 하는 중재자입니다.

REST API란?

REST 원칙을 적용하여 서비스 API를 설계한 것을 말합니다.

CORS란?

CORS(Cross-Origin Resource Sharing)란 웹 브라우저에서 외부 도메인 서버와 통신하기 위한 방식을 표준화한 스펙입니다. 서버와 클라이언트가 정해진 헤더를 통해 서로 요청이나 응답에 반응할지 결정하는 방식으로 교차 출처 자원 공유(cross-origin resource sharing)라는 이름으로 포준화 되었습니다.

CORS가 왜 필요한가요?

웹 브라우저는 보안 상의 이유로 스크립트가 동일 출처 정책(Same-Origin Policy)에 따라 자신의 출처(도메인, 프로토콜, 포트)와 다른 출처의 리소스에 접근하는 것을 제한합니다. CORS는 이러한 제한을 완화하기 위한 표준 방법입니다. CORS를 사용해 보안 정책을 유지하면서 필요한 자원 접근을 허용하는 중요한 역할을 합니다.

CORS에 대처하는 방법과 우회하는 방법

개발자가 테스트 혹은 개발 환경에서 웹 브라우저 실행 옵션이나 플러그인을 통해 동일 출처 회피하는 방법이 있습니다.
CORS 구현이 안되어 있는 서버로 ajax 요청을 해야하지만 서버쪽 컨트롤이 불가능할 경우: jsonp 방식으로 요청하는 방법이 있습니다.
서버 설정 수정: ajax 요청을 해야 하는 다른 도메인의 서버를 클라이언트와 같이 개발하거나 서버 개발쪽 수정 요청이 가능한 경우: 서버에서 CORS 요청이 허용되도록 구현합니다.
프록시 서버 사용: 클라이언트와 서버 사이에 프록시 서버를 두어 CORS 문제를 해결할 수 있습니다. 프록시 서버는 클라이언트의 요청을 받아 서버로 전달하고, 서버의 응답을 다시 클라이언트로 전달합니다.

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Max_Age: 3600
Access-Control-Allow-Headers: Origin,Accept,X-requested-With,Content-Type,Access-Control-Request-Method,Access-
Control-Request-Headers,Authorization

Access-Control-Allow-Origin: 요청을 허용하는 출처, '*' 이면 모든 곳에 공개되어 있음을 의미합니다.
Access-Control-Allow_Methods: 요청을 허용하는 메서드, 기본값은 GET,POST라고 보면 됩니다. 이 헤더가 없으면 GET과 POST요청만 가능합니다. 만약 이 헤더가 지정되어 있으면, 클라이언트는 헤더값에 해당하는 메서드일 경우에만 실제 요청을 시도하게 됩니다.
Access-Control-Max-Age: 클라이언트에서 preflight의 요청 결과를 저장할 기간을 지정. 클라이언트에서 preflight 요청의 결과를 저장하고 있을 시간입니다. 해당 시간 동안은 preflight 요청을 다시 하지 않게 됩니다.
Access-Control-Allow_Headers : 요청을 허용하는 헤더

웹 브라우저 실행 옵션, 플러그인

1-1. 웹 브라우저 실행 옵션: 웹브라우저 실행 시 외부 요청을 허용하는 옵션을 사용, same origin policy는 결국 클라이언트인 웹 브라우저가 요청을 해도 되는지 판단해서 결정하는 것으로 이 과정만 무시한다면 어디든 요청하지 못할 이유는 없습니다. 크롬같은 웹 브라우저들은 실행 시 커맨드 라인 옵션을 통해서 외부 도메인 요청가능 여부를 확인하는 동작을 무시하게 할 수 있습니다.

1-2. 플러그인: 외부 요청을 가능하게 해주는 플러그인 설치, 서버에서 받은 요청의 응답에 특정 header(Access-Control-Allow-Origin: *)만 추가하면 웹 브라우저가 요청이 가능한 사이트로 인식하여 요청이 가능합니다. 크롬의 경우 웹스토어에 요청을 가로채서 응답에 위 header를 추가해주는 플러그인이 있습니다. 웹스토어에서 cors로 검색하면 확장 프로그램 검색 결과에서 찾을 수 있습니다.

jsonp방식이란?

웹 브라우저에서 css나 js 같은 리소스 파일들은 동일 출처 정책에 영향을 받지 않고 로딩이 가능합니다. 이런 점을 응용해서 외부 서버에서 읽어온 js 파일을 json으로 바꿔주는 일종의 편법적인 방법입니다. 단점은 리소스 파일을 GET 메서드로 읽어오기 때문에 GET 방식의 API만 요청이 가능합니다.

(브라우저 저장소의 차이점) 로컬 스토리지와 세션 스토리지, 쿠키에 대해서 설명해주세요.

로컬 스토리지는 HTML5에서 제공하는 클라이언트측 데이터 저장 메커니즘입니다. 데이터는 브라우저의 로컬에 영구적으로 저장됩니다. 사용자가 페이지를 닫고 다시 열어도 데이터는 보존되지만 다른 브라우저에서 열면 유지되지 않습니다.
JS를 이용해 데이터를 설정하고, 다시 읽고 삭제 가능합니다.

세션 스토리지도 HTML5에서 제공하는 클라이언트측 데이터 저장 메커니즘입니다. 데이터는 브라우저 세션 동안만 유지됩니다. 즉 브라우저를 닫으면 데이터가 삭제됩니다.
JS를 사용하여 데이터를 설정하고 읽고 삭제 가능합니다.
주로 임시적인 데이터나 세션 동안 필요한 정보를 저장하는데 사용됩니다.

쿠키는 클라이언트와 서버 사이에 상태 정보를 유지하는데 사용되는 작은 데이터 조각입니다. 브라우저가 서버로부터 쿠키를 받아서 저장하고, 나중에 같은 서버에 요청할 때마다 쿠키를 함께 전송하는 방식입니다. 만료 날짜를 설정하여 지속성을 제어할 수 있습니다.
주로 사용자 로그인 상태 유지, 사용자 환경 설정, 사용자 추적 등 다양한 용도로 사용됩니다.

세션이란?

웹 개발에서 사용자가 웹 서버에 접속하여 브라우저를 닫을 때까지 유지되는 상태

세션 하이재킹이란?

사용자의 세션을 도용하여 해당 사용자로 위장하여 시스템에 접근하는 공격 기법입니다.

쿠키랑 세션의 차이?

쿠키는 클라이언트에 저장되는 작은 데이터 파일이고, 세션은 서버 측에서 관리되는 사용자 상태의 일부입니다. 보안적으로 더 안전한 정보 관리가 필요한 경우, 세션을 사용하는 것이 일반적으로 권장됩니다.

쿠키의 종류에 대해서 설명해주세요.

세션 쿠키 (Session Cookies):
보통 만료시간(Expire date) 설정하고 메모리에만 저장되며 브라우저 종료시 쿠키를 삭제한다.
지속 쿠키 (Persistent Cookies):
장기간 유지되는 쿠키 파일로 저장되어 브라우저 종료와 관계없이 사용한다.
보안 쿠키 (Secure Cookies):
HTTPS 에서만 사용되도록 설정된 쿠키. 쿠키 정보가 암호화되어 전송된다.

HttpOnly 설정:
HttpOnly 쿠키는 클라이언트 측 JavaScript에서 접근할 수 없도록 제한된 쿠키.
XSS(Cross-Site Scripting) 공격을 예방하기 위해 사용.
SameSite 설정:
SameSite 쿠키는 Cross-Site Request Forgery (CSRF) 공격을 방지하기 위한 쿠키 설정.
SameSite=Strict, SameSite=Lax

⭐️ CSRF, XSS 공격에 대해 말해보세요.

CSRF(Cross-Site Requset Forgery) 크로스 사이트 위조 요청 공격은 사용자가 인증된 세션을 통해 악의적인 요청을 수행하게 만드는 공격입니다. CSRF 공격은 사용자가 신뢰할 수 있는 웹 사이트에 로그인한 상태에서 다른 웹사이트를 방문했을 때 발생합니다. 데이터 도용 및 손실, 금전적 손실, 계정 탈취 및 설정 변경 등의 위험이 있습니다.

XSS(Cross-Site Scripting)는 공격자가 악성 스크립트를 신뢰할 수 있는 웹사이트에 삽입하여 다른 사용자 브라우저에서 실행되도록 하는 공격 기법입니다. 개인 정보 탈취, 피싱 공격, 웹사이트 변조, 악성 코드 배포 등의 위험이 있습니다.

쿠키 메서드와 프로퍼티에 대해 설명해주세요.

쿠키 메서드로는 document.cookie로 현재 페이지에 설정된 모든 쿠키를 가져오거나 설정할 수 있고 encodeURIComponent()는 쿠키에 저장할 값이나 이름이 안전하게 인코딩할 때 사용할때 사용합니다. 반대로 디코딩할 때는 decodeURIComponent() 함수를 이용합니다.

쿠키 프로퍼티로는 쿠키의 이름과 값이 반드시 설정되어야 하기 때문에 name=value가 있고, expires=date로 쿠키의 만료 날짜를 설정해줄 수 있습니다. 또 path로 쿠키의 유효한 경로, domain으로 쿠키가 유효한 도메인을 설정할 수 있습니다.
보안 관련해서 HttpOnly 프로퍼티를 설정해 클라이언트측 JS에서 쿠키에 접근할 수 없도록 해 XSS 공격을 방지할 수 있고 secure 설정으로 쿠키가 HTTPS 연결을 통해서만 전송될 수 있게 할 수 있습니다.

각 공격을 방어할 수 있는 방법은?

CSRF 공격 방지 방법은 CSRF 토큰을 사용해 각 요청에 대한 고유한 CSRF 토큰을 생성하고, 서버는 이 토큰을 검증하여 요청이 신뢰할 수 있는 출처에서 왔는지 확인하는 방법이 있습니다. 또 서버는 요청의 Referer 헤더를 확인하여 요청이 올바른 출처에서 왔는지 검증하는 방법이 있습니다.
쿠키의 SameSite 속성을 Strict 또는 Lax로 설정하여 크로스 사이트 요청에서 쿠키가 전송되지 않도록 할 수도 있습니다.
또한 민감한 작업에 대해서는 재인증(비밀번호 입력 등)을 요구하여 실제 사용자 인증을 강화하고, CORS를 적절히 설정하여 신뢰할 수 있는 도메인만 서버 자원에 접근할 수 있도록 제한합니다.

XSS 공격은 다음과 같은 방법으로 예방할 수 있습니다. 사용자 입력 값을 철저히 검증하고, 사용자 입력이 포함된 모든 출력을 HTML, JavaScript, CSS 등 해당 문맥에 맞게 적절히 인코딩합니다. 또 웹서버에 콘텐츠 보안 정책 CSP(Content Security Policy)를 설정하여 브라우저가 신뢰할 수 있는 소스에만 스크립트를 로드하도록 합니다.
쿠키에 HttpOnly 속성을 설정하여 클라이언트측 스크립트(JS)를 통해 접근할 수 없도록 합니다.

https를 사용합니다.

✏️ 용어 정리
인코딩: 데이터를 특정 형식으로 변환하는 과정. 보안을 강화하고 데이터를 안전하게 전달하기 위해 사용된다.
ex_ HTML 인코딩은 사용자가 입력한 <, >, & 같은 문자를 <, >, & 등으로 변환하여 브라우저가 이들을 HTML 태그나 엔티티가 아닌 텍스트로 해석하도록 만든다.

브라우저 상태코드

2xx: 클라이언트 요청 성공적으로 처리

3xx: 요청을 완료하기 위해 유저 에이전트(주로 웹 브라우저, 클라이언트 프로그램)의 추가 조치 필요

4xx: 클라이언트 오류 - 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음

5xx: 서버 오류

참고

HTTP GET, POST 방식에 대해 설명해주세요.

GET 방식은 일반적으로 서버에서 정보를 조회할 때, 요청에 필요한 데이터를 URL에 붙여서 전송합니다.
POST 방식은 서버에 정보를 입력 또는 추가할 때 사용합니다. 요청에 필요한 데이터를 HTTP request body 부분에 담아 전송합니다.

PUT과 POST의 차이점을 아시나요?

PUT 메서드는 클라이언트가 서버의 특정 리소스에 데이터를 저장하거나 업데이트할 때 사용됩니다. 동일한 요청을 여러 번 보내더라도 결과가 동일한 멱등성이 보장되는 특징이 있습니다. 즉, 동일한 데이터를 같은 URI에 요청을 여러번 보내도 결과는 항상 동일한 리소스가 저장됩니다. (전체 업데이트)

POST 메서드는 서버의 리소스에 데이터를 제출하여 새로운 리소스를 생성하거나 서버에서 특정 작업을 수행할 때 사용됩니다. 여러 번 요청시 매번 다른 결과를 낼 수 있어 멱등성을 보장하지 않습니다. 예를 들어, 동일한 POST 요청을 여러 번 보내면 새로운 리소스가 그때마다 생성될 수 있습니다. → 리소스를 추가하거나 서버가 정의한 작업을 수행(전체 또는 부분 데이터 제출 가능)

PUT은 특정 리소스를 정확히 지정하고 업데이트하거나 생성할 때, POST는 새로운 리소스를 생성하거나 서버에서 정의된 작업을 수행할 때 유용합니다.