● 당신은 TCP의 신뢰성을 보장하는 방법에 대해 이야기합니까, 간단히 설립 TCP 연결 및 해제 절차
참고 대답 :
TCP는 신뢰성을 보장합니다 :
(1) 서열 번호, 승인, 재송신 타임 아웃
데이터가 수신 측에 도착, 수신 측이 데이터 세그먼트가 받아야하는, 승인 번호, 데이터 시퀀스 번호를 설명한다 다음번에 수신되었는지를 나타내는 확인 응답을 전송해야한다. 보낸 사람이 확인 응답이 수신되지 않는 지연을 보낸 경우, 승인 후 발신자 일정 시간 대기 후 재전송 될 것이다, 손실 수, 데이터의 손실이 전송이있을 수 있습니다. 이 시간은 일반적으로 2 * RTT (라운드 트립 시간 구간) + 오프셋 값.
(2) 창 제어 및 고속 재송 제어 / 고속 재전송 (중복 확인 응답)
TCP는 창 크기가 확인을 위해 기다릴 필요가없는 창 크기 내에서 수단, 데이터의 다음 조각을 보내기 전에 응답을 기다릴 필요가 없습니다 전송 속도를 높이기 위해 창 컨트롤을 사용하고 최대로 데이터를 전송을 계속할 수 있습니다. 당신이 윈도우 컨트롤을 사용하지 않는 경우, 각 데이터의 확인이 재전송 될받지 못했습니다.
상기 데이터 세그먼트는 각각의 전송 데이터 뒤에 1001년에서 2000년까지을 잃은 경우 I 1001의 시작을 나타내는 데이터를 수신하고, 응답으로 승인 번호 (1001)를 전송하도록 계속해서, 상기 제어 창 것이다 사용 송신단 동일한 응답 경우 세 번 받는다 즉시 재전송 될 것입니다,하지만 데이터를 수신 할 수있다가 상황이 있지만, 일부 응답은 보낸 사람이 데이터 세그먼트가 손실 된 경우 있음을 알고 있기 때문에이 재전송되지 않습니다, 누락, 수신기는하지 않습니다 그것을 드릴 것입니다, 생각 나게 미친 것 ......
(3) 폭주 제어
윈도우가 주어진다면 큰, 연속 전송 끝이 많은 양의 데이터가 네트워크 혼잡이 발생할 수 있습니다 전송, 심지어 네트워크가 원인 (우리가 네트워크를 사용, 미친 물론, 차단됩니다, 그래서 큰 처리량 머리, 무엇인가) 마비. 따라서이 수행 TCP 혼잡 제어를 방지하기 위해서이다.
느린 시작 : 각의 (a RTT 후) 확인 응답을받은 후, 1 창 크기를 시작, 혼잡 윈도우를 정의, 혼잡 윈도우 크기 * 2.
혼잡 회피 : 일반적으로 느린 시작 임계 값을 설정 65536를 시작하도록 설정되어 있습니다. 혼잡 기피는 혼잡 윈도우 크기가 충돌 윈도우의 임계치가 더 이상 상승하지 도달하지만 언제 가산기의 증가 (각각의 확인 응답 / 각 RTT, 혼잡 윈도우 크기 + 1) 피 정체하는 것이 가능하게 될 수있다.
혼잡 한 부분으로 볼 재전송 시간 제한은 재전송 타임 아웃의 경우, 우리는 하나의 초기 값으로 첫번째 세트에 현재 윈도우 크기의 절반, 창 크기 임계 값을 필요로하고 느린 시작을 다시 입력합니다.
고속 재전송 즉시 얼굴 3 번 재전송 확인 응답 (고속 재송신 제어) 반복은 대표적인 3 개 개의 세그먼트를 수신하지만 그 세그먼트 전에 하나가 될 것이다 손실된다.
그런 다음, 첫 번째 임계 값은 느린 시작 임계 값 +3의 크기로 현재 창 크기의 절반, 다음 혼잡 윈도우 크기로 설정됩니다.
이 달성 될 수있다 : TCP 트래픽, 네트워크 처리량의 점진적인 증가를 보였으며,와 혼잡을 줄이고, 천천히 프로세스에 상승 처리량 때, 네트워크 마비가 쉽게 발생하지 않습니다.
TCP 연결 설정 및 해제 :
세 방향 핸드 셰이크 :
1. 클라이언트 SYN 플래그 비트가 1로 무작위로 생성 된 값 SEQ = J를 설정하고, 패킷이 서버에 전송되어, 클라이언트는 서버 응답을 기다리는 상기 SYN_SENT 상태가된다.
2. 서버는 플래그로부터 패킷 데이터 연결을 설정하는 SYN = 1 아는 클라이언트 요청 비트 수신 서버 SYN와 ACK 플래그 비트는 1, ACK = J + 1, 무작위로 생성 된 값 SEQ = K는 데이터에 설정된 확인 클라이언트의 연결 요청 패킷은 서버 SYN_RCVD 상태가됩니다.
3. 클라이언트는 검사, 승인을 수신 한 ACK J + 1, ACK 올바른 ACK 플래그 (1), ACK = K + 1로 설정하고, 패킷을 서버로 전송되고있는 경우, 서버 점검 ACK 1 여부 여부 K + 1, ACK는 올바른 경우, 연결이, 클라이언트를 설치하고 서버, 세 방향 핸드 셰이크를 완료 한 다음 클라이언트와 서버 사이에 데이터를 전송을 시작할 수 상태를 설립 들어간다, 1입니다.
넷 웨이브 :
TCP 연결은 전이중 (full-duplex)이기 때문에, 따라서 각 방향으로 개별적으로 종료해야하며,이 원칙은 하나의 작업이 방향으로 연결을 종료하기 위해 FIN을 전송, 데이터 전송 완료,하지만 수단 경우는 FIN을 수신한다는 것입니다 가 더 이상 수신 데이터입니다 방향의 흐름에 대한 자료는 없지만, 여전히이 방향도 FIN을 보낼 때까지 TCP 연결을 통해 데이터를 보낼 수 있습니다. 우선 다른 수행하면서 수동 가까이 근접 활성을 수행 한 것이다.
1. 데이터 전송이 완료되면, 클라이언트 애플리케이션 프로세스는 클라이언트가, 그 클라이언트가 여전히 수신 수도있는 데이터가 서버에 의해 전송 FIN_WAIT_1 상태로 진입 연결 방출 부하게하고, 데이터 송신을 정지한다.
서버가 FIN을 수신 한 후 2. ACK 클라이언트로 전송 승인 번호가 수신 된 시퀀스 번호 + 1 서버가 CLOSE_WAIT 상태로된다. 상태 수령 후 클라이언트로 FIN_WAIT_2.
서버가 전송할 어떠한 데이터도없는 경우 3. 서버는 클라이언트의 확인을 대기 서버 LAST_ACK 상태로 들어가는 FIN 패킷을 보낸다
서버가 FIN 패킷을 수신 한 후, 클라이언트 (4), 상기 수신 된 시퀀스 번호 +1의 시퀀스 번호를 확인하기 위해 서버에 ACK 패킷을 송신한다. 가까이 후 연결 (세그먼트의 최대 생존 기간 MSL),이 경우 클라이언트는 2MSL을 기다리고 TIME_WAIT 상태가된다.
● 차이점에 대해 답변 해주세요 HTTP 및 HTTPS, HTTPS 및 단점은 무엇입니까?
참고 대답 :
HTTP 프로토콜 및 HTTPS 프로토콜의 차이를 다음과 같이 :
데이터 전송 네트워크의 맑은 1) HTTP 프로토콜은 데이터 전송 프로토콜은 HTTPS HTTPS는 더 높은 수준의 보안을 가지고, TLS 암호화입니다
2) HTTPS TCP 세 방향 핸드 셰이크 단계, 핸드 셰이크 SSL에 대한 필요성 후와의 대칭 암호화 키 계약을 사용하여 암호화
3) HTTPS 프로토콜은 서버 인증서 요청, 해당 브라우저 설치 루트 인증서가 필요합니다
4) HTTP 프로토콜 포트 80, HTTPS 프로토콜 포트 (443)
HTTPS 장점 :
핵심 프로세스를 사용하여 암호화 된 HTTPS 전송 데이터, 높은 보안 때문에
HTTPS 프로토콜은 사용자와 서버를 인증 할 수있는 올바른 사용자 및 서버로 데이터를 전송해야합니다
HTTPS 단점 :
HTTPS 핸드 셰이크 위상 지연 이상 : HTTP 세션에 앞서 또한, SSL 핸드 셰이크가 필요하기 때문에 HTTPS 프로토콜 핸드 쉐이크 위상 지연이 증가하므로
HTTPS 배포 비용 : 프로토콜은 CA 인증서를 구입하는 것이 필요하다, 그래서 그들의 안전을 확인하기 위해 인증서의 사용을 필요로하는 한편 HTTPS에, 서버 구성에 대한 필요성은 다른 한편으로 인한 HTTPS의 사용 프로토콜은 암호화 및 암호 해독 계산을 필요로 더 많은 CPU 자원을 복용하거나, 높은 숫자
당신이 HTTP 리턴 코드에 대해 이야기합니까 ●
1XX : 표시 정보 - 처리는 계속 요청이 수신되었는지 나타낸다.
가 2xx : 성공 - 요청이 성공적으로 수신 된, 접수 이해 있음을 나타냅니다.
3xx의 : 리디렉션 - 한 단계 더 가야 요청을 수행합니다.
4XX는 : 클라이언트 오류 - 요청에 구문 오류가 있습니다 또는 요청이 달성 될 수 없다.
5XX : 서버 측 오류 - 서버는 합법적 인 요구를 달성하지 못했습니다.
일반적인 상태 코드는, 상태가 아래의 상세한 설명에서 설명했다.
200 OK : 클라이언트 요청이 성공했습니다.
요청은 원하는 얻어지는 범위를 포함한 요청 클라이언트까지의 범위를 표시한다 (206) 부분 콘텐츠 서버 올바르게 부분 GET 요청을 처리 한 HTTP 또는 동시에 슬라이스 다운로드 구현
300 개 다중 선택 (옵션 재) : 자신 중 하나를 선택하는 브라우저 / 사용자가 선택한 피드백 정보에 대한 요청 된 자원의 시리즈.
301 (영구 리디렉션) 영구적으로 이동 : 리소스가 새 위치로 영구적으로 이동 한, 리소스에 대한 향후 액세스는 여러 URI 중 하나이 응답 등을 사용해야합니다.
302 이동 일시 (임시 리디렉션) 이제 다른 URI로부터 임시 자원 요청에서 얻어진
304 : 비 개질 : 클라이언트가 문서의 내용이 변경되지 않은 상태 (캐시를 직접 사용할 수있는) 함유 물을 포함하지 않으며, 304이 반환되고, 응답을 통해 허용하는 GET 요청 및 요청 보류 조건을 전송하는 경우.
서버가 요청을 수신하지만, 서비스를 제공 거부 : 403 금단.
당신은 TCP 세 방향 핸드 셰이크 네 흔들며 과정과 이유에 대해 이야기합니까 ●
참고 대답 :
C-> SYN -> S
S-> SYN / ACK-> C
C-> ACK-> S
세 방향 핸드 셰이크 이유 :
// 세 가지 다른 견해가 있습니다 :
자원 1. 폐기물 관점 : 견적을 "컴퓨터 네트워크"의심과 운동 솔루션시에 Xiren에서
세 방향 핸드 셰이크 서버에 의한 자원의 낭비를 갑자기 서버에 연결 요청 패킷을 방지 수송에 실패했습니다. 예를 들어, 클라이언트는 SYN을 보내지 만 있기 때문에 네트워크 혼잡, 노드에서 SYN 패킷이 오래 유지됩니다. 클라이언트는 가까운 데이터를 송신 한 후 연결을 다음 SYN 패킷을 재전송하고 올바르게 TCP 연결을 설정합니다. SYN 패킷 후 연결 해제 실패는 서버에 도달합니다. 두 번째 핸드 셰이크의 전제 아래, 서버는이 클라이언트가 시작한 또 다른 요청이라고 생각하고 SYN를 보내, 우리는 데이터를 전송하기 위해 클라이언트에 대한 기다리고있는 서버 측 소켓 소켓을 작성합니다. 클라이언트가 새 요청을 시작하지 않기 때문에, 그것은 SYN 서비스 측 떨어질 것이다. 이 시점에서 클라이언트 서버는 자원의 낭비의 결과로 데이터를 보낼 기다립니다.
2, 심판의 신뢰성 :
"문제의 본질은 채널이 신뢰성이되지 않는 것입니다, 통신이 이중이 필요합니다 : 두 개의 채널이 막히는 경우 또 다른 희망을 결정하기 위해, 당신은 세 개의 송신 및 수신 패킷, 즉 세 방향 핸드 셰이크를 사용해야합니다 문제는 동의합니다. 당신이 어떤 정보를 메시지에 포함되어 있는지 여부를이 문제를 해결하기 위해, 통신은 세 번 이론적 최소이다. TCP 세 방향 핸드 셰이크는 그 자체 요구 사항이 아니라, "안정적으로 신뢰할 수없는 채널을 충족시킬 수 있도록 정보의 전송, "수요가 발생했습니다.
세 당사자가 서로의 최소 값을 만들 수 있습니다 명확받을 수 있도록하는 것입니다. 추가 악수를 개선하되 추가에 다음 이론적으로, 핸드 쉐이크가 채널을 확신 할 수있는 횟수에 상관없이는 "신뢰할 수있는"이지만 "가능"입니다 최소 3 방향 핸드 셰이크에 의해 확인 될 수 있으며, "그것을 사용할 수 있습니다."이 결론 신뢰성. 또한보다 안정적인 전송 TCP는을 보장하기 위해 재전송 메커니즘에 의존하는 것입니다
3. 초기 시퀀스 번호 :
각면은 (오히려 악수의 수보다는) 신뢰성을 보장 제한 시간 재전송을 오는 다시하면서 이리저리 TCP 연결 설정 핸드 셰이크는, 본질적으로, 신뢰할 수있는 양방향 통신 링크를 설정하는 것입니다. SYN ACK 및 수동 개방 SYN가 SYN-ACK에 병합 있도록 TCP 세 방향 핸드 셰이크 최적화의 결과입니다, 사실, 그것이 있기 때문에 연결을 설정할 수있는 4 방향 핸드 셰이크해야한다, 제로.
이 두 방향으로 연결되어 있기 때문에 핸드 셰이크 동작이 두 양방향 초기 시퀀스 번호를 확인하도록 컴파일 바이트 액세스 전송에 TCP 시퀀스 번호는,이 두 개의 일련 번호에 필요한, 모든 바이트 핸드 쉐이크 절차를 전송하지 않습니다 오직 초기 시퀀스 번호를 결정하는 단계를 포함한다.
다음과 같이 TCP의 네 손을 흔들었다 :
C-> FIN-> S
S-> ACK-> C
S-> FIN-> C
C-> ACK-> S
네 흔들며 이유 : 때문에 어플리케이션 계층에서 연결의 확대 제어 패시브가 FIN 패킷을 수신 할 때 폐쇄 TCP 스택은 직접 확인 응답 패킷의 ACK, 통신의 폐쇄 단부의 우선 순위를 전송한다. 그런 다음 응용 프로그램 계층에 통보, 응용 계층은 FIN 패킷을 보낼 때 결정합니다. 애플리케이션 계층 기능 == 0 피어가 연결을 종료할지 여부를 판단하기 위해 판독 시스템 콜을 사용한다. (파티 떨어져 그 주도권은 FIN을 전송 한 후 데이터를 전송하지 않습니다, 또한 데이터를 수용해야 할 수도 있습니다)
● 윌 TCP 핸드 쉐이크 왜 두 번? 왜 사?
아니 사 :
원래 악수를하고 모든 필요가 양방향 수 유니콤에서 확인 할 수처럼 손을 흔들었다가 모델이되어야한다되었습니다 :
1. 클라이언트가 서버 syn0로 전송
2. 서버가 syn0를 수신 ACK 회신 (syn0 + 1)
3 서버 SYN1 전송
4. 클라이언트 SYN1를 수신하고, ACK를 회신 (SYN1 + 1)
TCP 바와 같이, 전이중, 상위 4 개 데이터가 양 방향으로 정확하게 확인할 수있다 도착 2-3 단계하지만 더 위로 핸드 셰이크의 효율성을 촉진하기 위해 결합 될 수있는 링크 아래가없는, 모두가 3 방향 핸드 셰이크가된다.
당신은 TCP 혼잡 제어를위한 보이나요 ●?
참고 대답 :
프로세스 혼잡 윈도우 크기는 느린 시작 임계 값을 초과 할 때까지, 다음 혼잡 회피 단계, 혼잡 윈도우의 선형 성장의 크기를 입력 기하 급수적으로 증가 할 때 느린 시작 임계 값 혼잡 시간을 표시하도록 설정되어 네트워크 혼잡,이 (세 개의 중복 ACK 또는 시간 초과) 절반 크기는 혼잡 윈도우 크기 0에서 느린 출발을 재 입력 한.
빠른 재전송과 빠른 복구 즉시 기다릴 수 없습니다 (가능한 세그먼트가 다른면에 도달하지 않는 한 빨리 알고 보낸 사람을 가능하게하기 위해) 확인을 반복 수신자가 발행 한 빠른 재전송 요구 사항은이 세그먼트의 수령 후 순서로 보낼 때까지 데이터를 피기 백. 빠른 재전송 알고리즘을 지정, 한 보낸 사람이 세 개의 연속 중복 승인 즉시 다른 세그먼트 아직받지 못한 재전송보다는 재전송 타이머 설정 시간이 만료 기다릴 계속해야받을 수로
두 가지를 참고 :
1. TCP 혼잡 제어 알고리즘은 사가지, 즉 느린 시작, 혼잡 회피, 빠른 재전송과 빠른 회복을 가지고
고속 재전송 빠른 복구보다는 느린 시작의 구현 후 2. 4 점은, 느린 시작을 시작합니다,하지만 수행 빠른 복구 알고리즘, 임계 값과 혼잡 윈도우의 크기는 현재의 혼잡 윈도우 / 2로 설정하고, 혼잡 회피 알고리즘을 구현하기 시작하지 않을 경우.