이 기사에서는 컴퓨터 네트워크에 관해 ByteDance가 가장 좋아하는 프런트엔드 인터뷰 질문 중 일부를 공유할 것입니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.
참고: 각 질문 앞에 나타나는 (xx) 숫자는 이 질문의 빈도를 나타냅니다. 이 컴퓨터 네트워크 기반은 30개 이상의 프런트 엔드 인터뷰에서 수집된 질문과 해당 답변 및 참조 링크를 기반으로 합니다. . 기다리다. 기사의 내용은 제안을 받은 사람이 편집한 것입니다.
HTTP 캐시는 강력한 캐시와 협상된 캐시로 구분됩니다.
먼저 Cache-Control을 통해 강력한 캐시가 사용 가능한지 확인합니다. 캐싱
그렇지 않은 경우 협상 캐시 단계에 진입하여 HTTP 요청을 시작합니다. 서버는 요청 헤더에 If-Modified-Since 및 If와 같은 조건부 요청 필드가 포함되어 있는지 여부로 리소스가 업데이트되는지 확인합니다. -None-Match:
리소스가 업데이트되면 리소스와 200 상태 코드를 반환합니다.
리소스가 업데이트되지 않으면 브라우저에 직접 캐시를 사용하여 리소스를 얻도록 지시합니다
1xx: 프로토콜이 현재 중간 상태에 있으며 후속 요청이 필요함을 나타냅니다.
2xx: 요청이 성공했음을 나타냅니다.
3xx: 리디렉션 상태가 필요함을 나타냅니다.
4xx: 요청이 성공했음을 나타냅니다. 요청 오류 x 5xx: 서버 측 오류
일반 상태 코드:
101 HTTP에서 WebSocket으로 전환 요청 프로토콜
200 요청 성공, 응답 본문 있음
301 영구 리디렉션: 캐시됨
302 임시 리디렉션: 캐시되지 않음
304 협상 캐시 적중
403 서버 액세스 금지
404 리소스를 찾을 수 없음
4 00 요청 오류
500 서버 측 오류
503 서버 사용 중
예를 들어 http://baidu.com에서 https://baidu.com
도메인 이름이 변경되었습니다
(2) 질문 : 일반적인 HTTP 요청 방법, 차이점 및 용도는 무엇입니까? .http/1.1 규정 다음 요청 방법 :
3방향 핸드셰이크가 필요한 이유: 상대방의 송수신 기능을 확인하기 위해.
삼자 악수의 주요 프로세스:
처음에는 양쪽 모두 CLOSED 상태에 있다가 서버가 특정 포트를 수신하기 시작하고 LISTEN 상태로 들어갑니다.
클라이언트가 적극적으로 연결을 시작하고 SYN을 보낸 후 다음과 같이 변경됩니다. SYN-SENT, seq = x
서버가 이를 수신한 후 SYN seq = y 및 ACK ack = x + 1(클라이언트가 보낸 SYN에 대해)을 반환하고 SYN-REVD
이 됩니다. 그런 다음 클라이언트는 다시 ACK seq = x + 1을 보내고 ack = y + 1을 서버에 제공하고 서버가 ACK를 받으면 ESTABLISHED에도 진입합니다. 따라서 ACK의 직렬화는 1씩 증가해야 합니다. 피어 확인이 필요한 모든 것은 TCP 메시지의 직렬화를 소비합니다
왜 두 번은 안 될까요?
고객님의 수신능력을 확인할 수 없습니다.
클라이언트가 먼저 SYN 메시지를 보냈지만 네트워크에 그대로 남아 있으면 TCP는 패킷이 손실되었다고 생각한 다음 다시 전송하고 두 번의 핸드셰이크를 통해 연결이 설정됩니다.4번은 어떨까요?클라이언트가 연결을 닫을 때까지 기다립니다. 하지만 나중에 패킷이 서버에 도착하면 서버는 이를 수신한 후 해당 데이터 테이블을 전송하고 링크가 설정됩니다. 그러나 이때 클라이언트가 연결을 종료했기 때문에 링크 리소스가 낭비됩니다.
4번 이상도 괜찮지만, 3번이면 충분합니다
Wave 4번처음에는 ESTABLISH 상태이고 이후 클라이언트는 seq =로 FIN 메시지를 보냅니다. p, FIN-WAIT-1
왜냐면 기다리지 않으면 서버에 클라이언트로 보낼 데이터 패킷이 여전히 많고 이때 클라이언트 포트는 새로운 응용 프로그램이 점유하면 쓸모없는 데이터 패킷이 수신되어 데이터 패킷 혼란이 발생하므로 가장 안전한 방법은 새 응용 프로그램을 시작하기 전에 서버가 이를 보낼 때까지 기다리는 것입니다.
1 MSL은 4개의 웨이브에서 활성 종료 파티의 마지막 ACK 메시지가 마침내 피어에 도달할 수 있도록 보장합니다.
1 MSL은 피어가 ACK를 받지 못한 다음 재전송된 FIN 메시지가 도착할 수 있도록 보장합니다
**3번이면 서버 측의 ACK와 FIN이 하나의 웨이브로 결합됩니다. 이러한 긴 지연으로 인해 TCP FIN이 서버 측에 도달하지 못할 수 있으며 클라이언트는 계속해서 재전송하게 됩니다. FIN
참고정보
https://zhuanlan.zhihu.com/p/86426969
에 넣어야 합니다. 송신자가 너무 많이 보내면 수신자가 이를 소화할 수 없는 상황이 자주 발생하므로 수신 버퍼의 크기를 통해 송신자의 송신을 제어하는 흐름 제어가 필요합니다. 상대방의 수신 버퍼가 가득 차면 계속해서 보낼 수 없습니다. 이 흐름 제어 프로세스에서는 송신 측의 송신 창과 수신 측의 수신 창을 유지해야 합니다. TCP 슬라이딩 창은 송신 창과
수신 창두 가지 유형으로 나뉩니다. References
https://juejin.im/post/5e527c58e51d4526c654bf41#heading-38
Essence Different
Ajax, 즉 비동기식 JavaScript와 XML은 대화형 웹 애플리케이션을 만들기 위한 웹 개발 기술입니다. websocket은 브라우저와 서버 간의 실시간 통신을 가능하게 하는 HTML5의 새로운 프로토콜입니다.
삶의 다양한 주기:
websocket은 긴 연결이므로 세션이 항상 유지됩니다. ajax는 보내고 받은 후 연결이 끊어집니다. 적용 범위: websocket은 다음의 실시간 상호 작용에 사용됩니다. 프런트엔드 및 백엔드 데이터 ajax 비실시간 Initiator: AJAX 클라이언트 시작 WebSocket 서버와 클라이언트가 서로 푸시 긴 폴링과 짧은 폴링, WebSocket은 긴 폴링입니다. 예를 들어 전자 상거래 시나리오에서는 상품의 재고가 변경될 수 있으므로 적시에 사용자에게 반영해야 하므로 클라이언트는 계속 요청을 보내고 서버는 관계없이 계속 변경 사항을 확인합니다. 변경 여부에 대한 모든 정보가 반환됩니다. 이는 짧은 폴링입니다. 긴 폴링의 성능은 변경 사항이 없으면 반환하지 않지만 반환하기 전에 변경 사항이나 시간 초과(보통 10초 이상)를 기다린 후 반환할 필요가 없다는 것입니다. 요청을 보내므로 양측 모두 요청 수를 줄일 수 있습니다. 참조 링크 https://www.jianshu.com/p/3fc3646fad80 헤더(요청 및 응답 헤더)에 Connection: keep-alive를 설정하면 HTTP1.0 프로토콜이 지원되지만, HTTP1.1 프로토콜부터는 기본적으로 비활성화되어 있습니다. 기본적으로 연결 HTTP 일반 연결 유지 시간 초과를 설정할 수 있는 httpd 데몬이 있습니다. TCP 링크가 이 시간 이상 유휴 상태이면 닫힐 수도 있습니다. HTTP 헤더 TCP의 keep-alive에는 지원되는 세 가지 매개 변수가 포함되어 있습니다. 시스템 커널의 net.ipv4에 설정되어 있습니다. TCP 링크가 tcp_keepalive_time 동안 유휴 상태일 때 상대방의 ACK가 없으면 감지 패킷이 발생합니다. 수신되면 tcp_keepalive_probes가 전송될 때까지 tcp_keepalive_intvl마다 다시 전송됩니다. tcp_keepalive_intvl = 15 tcp_keepalive_probes = 5 tcp_keepalive_time = 1800 실제로는 HTTP가 있습니다 길고 짧은 링크는 없고 TCP 긴 연결만 가능합니다. 리소스 소비를 줄일 수 있는 여러 HTTP 요청을 시작합니다. 예를 들어 HTML을 한 번 요청하면 후속 JS/CSS/이미지 등을 요청해야 할 수도 있습니다. 참조 링크 https:/ /blog.csdn.net/weixin_37672169 /article/details/80283935 https://www.jianshu.com/p/3fc3646fad80 fetch는 관심사 분리를 준수하고 Promise를 사용하며 API가 더 풍부하고 Async/AWAIT를 지원합니다. 간단한 의미, 더 많은 의미 Isomorphic-Fetch에서 사용할 수 있어 참조 리소스에 편리합니다. Https:// /github.com/camsong/blog/issues/2 이유는 특히 전체 네트워크 환경이 열악할 수 있고 패킷 손실이 쉽기 때문에 발신자는 주의를 기울여야 합니다. 주로 세 가지 방법을 사용합니다: 느린 시작 임계값 + 혼잡 회피 느린 시작 임계값 + 혼잡 회피 혼잡 제어를 위해 일반적으로 말하면 , TCP는 주로 두 가지 핵심 상태를 유지합니다. 혼잡 창(cwnd) 그런 다음 초기 전송 기간 동안 비교적 보수적인 느린 시작 알고리즘을 사용하여 네트워크에 천천히 적응합니다. 발신자와 수신자는 먼저 3방향 핸드셰이크를 통해 연결을 설정하고 각각의 수신 창 크기를 결정합니다. 그런 다음 양쪽에서 정체 기간을 초기화하고 RTT(수신기 및 전송 지연)의 각 라운드 후에 정체 기간 크기는 느린 시작 임계값에 도달할 때까지 두 배로 늘어납니다. 그런 다음 혼잡 회피를 시작합니다. 혼잡 회피의 구체적인 방법은 이전 RTT의 각 라운드에서 혼잡 창을 두 배로 늘리고 이제는 각 라운드에서 1을 추가하는 것입니다. 빠른 재전송 TCP 전송 과정에서 패킷 손실이 발생하면 수신측에서는 반복적으로 ACK를 보냅니다. 예를 들어 5번째 패킷이 손실되고 6과 7에 도달한 후 수신됩니다. end는 5, 6, 7 모두 네 번째 패킷의 ACK를 보냅니다. 이때 송신자는 3개의 중복 ACK를 수신하면 패킷이 손실되었음을 알게 되면 RTO(타임아웃 재전송 시간)를 기다리지 않고 즉시 재전송합니다. ) 선택적 재전송: 선택적으로 메시지 헤더에 SACK 속성을 추가하고 왼쪽 가장자리와 오른쪽 가장자리를 통해 도착한 패킷을 표시한 다음 도착하지 않은 패킷을 다시 전송합니다. 빠른 복구 전송 측에서 3개의 중복 ACK를 수신한 후 패킷 손실이 발견되고 현재 네트워크 상태가 혼잡 상태에 들어간 경우 신속한 복구 단계로 진입합니다. 혼잡 임계값을 혼잡 창의 절반으로 줄입니다. 그러면 혼잡 창 크기가 혼잡 임계값이 됩니다 그러면 혼잡 창은 네트워크 조건에 맞게 선형적으로 증가합니다 은 특정 대상 주소에 대한 요청에 어떤 제약 조건이 있어야 하는지 확인하기 위해 프로브 요청을 보낸 다음 제약 조건에 따라 실제 요청을 보내도록 설계되었습니다. 예를 들어 도메인 간 리소스에 대한 사전 확인은 HTTP의 OPTIONS 메서드를 사용하여 먼저 전송됩니다. 도메인 간 요청을 처리하는 데 사용됩니다 공백으로 단어를 구분하고 줄바꿈으로 필드를 구분하는 것 외에는 제한이 없습니다. 텍스트뿐만 아니라 사진, 동영상과 같은 리소스도 전송할 수 있습니다. TCP/IP 기반의 전송이므로 이 기능을 상속합니다 요청-응답, 왔다 갔다 상태 비저장, 각 HTTP 요청은 독립적이고 관련이 없으며 기본적으로 컨텍스트 정보를 저장할 필요가 없습니다 단점: 일반 텍스트 전송은 안전하지 않습니다 TCP 링크를 재사용하면 피어 혼잡이 발생합니다. Stateless 긴 연결 시나리오에서는 전송을 피하기 위해 많은 양의 컨텍스트를 저장해야 합니다. 다수의 중복 정보 OSI 7계층 모델 application layer 프레젠테이션 레이어 세션 레이어 전송 레이어 네트워크 레이어 데이터 링크 레이어 물리 레이어 애플리케이션 계층: 애플리케이션 계층, 프리젠테이션 계층, 세션 계층: HTTP 전송 계층: 전송 계층: TCP/UDP 네트워크 계층: 네트워크 계층: IP 데이터 링크 계층 : 데이터 링크 계층, 물리 계층 UDP는 IP 특성을 상속하고 데이터그램을 기반으로 하는 비연결 전송 계층 통신 프로토콜입니다. TCP가 신뢰할 수 있는 이유는 무엇인가요? TCP의 신뢰성은 상태와 제어에 반영됩니다. 어떤 데이터가 전송되었는지, 어떤 데이터가 상대방으로부터 수신되었는지, 어떤 데이터가 수신되지 않았는지 정확하게 기록합니다. 이것이 TCP가 제공하는 기능입니다. Status 패킷이 손실되었거나 네트워크 환경이 열악한 경우 TCP는 특정 상황에 따라 동작을 조정하거나 자체 전송 속도를 제어합니다. 재전송, 제어 가능 반대로 UDP는 상태가 없고 제어할 수 없습니다. 다중 채널 참고자료
웹소켓을 아시나요?
HTTP 긴 연결을 구현하는 방법은 무엇입니까? 어느 시점에 시간이 초과되나요?
Q: Fetch API와 기존 요청의 차이점은 무엇인가요
텍스트, 사진, 비디오, 오디오 등은
text/image/audio/ 또는 application/json etc
tcp는 연결 지향적이고 안정적인 전송 계층 통신 프로토콜입니다
신뢰성은 상태 저장 및 제어 가능에 반영됩니다.
제어 가능하다는 것은 패킷 손실이 있거나 네트워크 상태가 좋지 않으면 점프한다는 의미입니다. 자체 동작에 맞게 전송 속도를 줄이거나
빠른 재전송
느린 시작 임계값(ssthresh)
Q: OPTION은 무엇을 합니까? OPTION 사용 예를 들어보시겠어요?
Q: http에 대해 알고 있나요? 어느 계층의 합의인가? (애플리케이션 레이어)
TCP는 연결 지향적이고 안정적인 전송 계층 통신 프로토콜입니다.
향상된 성능:
헤더 압축
더 많은 프로그래밍 관련 지식을 보려면 다음 사이트를 방문하세요:
프로그래밍 비디오 ! !
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
