처음으로 User-Agent 문자열을 대량으로 이해해야 했던 것은 SEO 프로젝트 중이었습니다 wpadminify.com, 실제 사람이 트래픽의 얼마나 많은 크롤러 얼마나 많은 것을 밖으로 작동하려고 서버 액세스 로그를 응시. 나는 모든 시작 문자열의 열을했다 Mozilla/5.0,모두 Safari 를 언급했고,그들 중 절반은 실제로 다른 브라우저 인 동안 하나의 브라우저가되는 것에 대해 거짓말을했습니다. 눈으로 읽는 것은 절망적이었습니다. 그것이 User-Agent 파서가하는 일이며,너무 많은 시간을 열심히 한 후에 나는 하나를 내장했습니다 Toolz.dev. 이것은 그것에 대한 가이드이며,그 뒤에있는 놀랍도록 지저분한 헤더에.
TL;DR: 툴즈 사용자 에이전트 파서 사용자 에이전트 문자열을 가져와 브라우저,렌더링 엔진,운영 체제,장치 유형 및 CPU 아키텍처로 분할합니다. 헤더's quirks 수요의 탐지 순서를 적용하므로 Chrome 및 모바일 Safari 가 실제 버전 토큰에서 읽혀지는 것처럼 Edge 는 잘못 읽히지 않습니다. 또한 알려진 봇에 플래그를 지정합니다. 모든 것이 클라이언트 측에서 실행됩니다: 업로드 없음,가입 없음,실제 로그 라인에 안전합니다.
User-Agent 문자열이란 무엇입니까?
User-Agent 문자열은 의 값입니다 User-Agent 브라우저나 HTTP 클라이언트가 거의 모든 요청과 함께 보내는 요청 헤더. 헤더는 에 정의되어 있습니다 RFC 9110는, HTTP 의미론 명세는, 서버가 요구를 하는 소프트웨어를 확인하는 시키고 제품 식별자와 코멘트의 순서로 그것을 설명합니다 실제로 브라우저, 그것의 버전, 연출 엔진, 운영 체계, 및 수시로 장치의 이름을 지정합니다.
의도는 합리적이었습니다: 서버가 응답을 조정하거나 통계를 수집 할 수 있도록 연결하는 방법을 알 수있는 방법을 제공하십시오. 현실은 문자열이 웹에서 자체보고 된 데이터 중 가장 신뢰할 수없는 부분 중 하나가 되었기 때문에 악의적 인 것이 아니라 명백한 독서가 일반적으로 잘못된 것이 될 때까지 20 년간의 호환성 해킹이 토큰에 토큰을 계층화했기 때문입니다.
다음은 Windows의 최신 Chrome 문자열입니다:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
모질라라고 주장하고,AppleWebKit 을 언급하고,Safari 라는 단어로 끝납니다. 그런 것들은 아닙니다; 크롬입니다. 이전의 모든 토큰 Chrome/126 는 역사적 퇴적물입니다. 가장 권위있어 보이는 토큰을 신뢰할 수 없기 때문에 파서가 정확하게 존재합니다.
User-Agent를 구문 분석하는 것이 오류가 발생하기 쉬운 이유는 무엇입니까?
헤더는 모방에 의해 성장했다. 초기 브라우저 전쟁에서 서버는 User-Agent 를 확인하여 보낼 페이지 버전을 결정했으며 종종 간단한 하위 문자열 일치로 서투르게 확인했습니다. 좋은 최신 페이지를 받기를 원하는 새로운 브라우저는 서버가 찾고 있던 토큰을 포함해야했기 때문에 각 브라우저는 이전 우승자를 복사했습니다. Netscape 는 스스로를 Mozilla 라고 불렀기 때문에 Internet Explorer 는 Mozilla 와 호환된다고 주장했습니다. WebKit 브라우저가 도착했을 때 그들은 Mozilla 와 KHTML 토큰을 가지고 다녔습니다. Chrome 은 WebKit 에서 포크되었으며 WebKit 을 스니핑하는 서버가 잘 처리 할 수 있도록 AppleWebKit 과 Safari 를 모두 유지했습니다. 그 결과 단일 문자열에는 정직하게 4 개의 다른 브라우저 계보의 이름을 포함 할 수 있습니다.
이것은 문자열을 읽는 모든 사람을위한 구체적인 함정을 만듭니다:
- Edge와 Opera는 모두 포함되어 있습니다
Chrome. Microsoft Edge가 추가되었습니다Edg/126.0.0.0그리고 Opera가 추가됩니다OPR/, 하지만 둘 다 가득 찼습니다Chrome/126크롬 기반이기 때문에 토큰. 먼저 크롬에 대한 테스트 및 당신은 크롬으로 모든 가장자리와 오페라 사용자를 레이블 것입니다. - Safari는 실제 버전을 숨깁니다. 데스크탑과 iOS에서 Safari는 사용자 대면 버전을 다음과 같이 보고합니다
Version/17.5토큰, 동안Safari/604.1끝부분에 가까운 토큰은 브라우저 버전이 아닌 WebKit 빌드 번호입니다. 읽기Safari/버전으로 그리고 당신은 의미없는 숫자를 얻습니다. - IOS 에서의 크롬은 Chrome's 엔진이 아닙니다. Apple은 모든 iOS 브라우저에서 WebKit을 사용해야 하므로 iPhone의 Chrome이 보고합니다
CriOS그리고 Blink 가 아닌 WebKit 을 실행합니다. iOS 의 Firefox 는FxiOS, 또한 WebKit. - Windows 11 이 문자열에 존재하지 않습니다. Microsoft는 NT 커널 토큰을 범프하지 않았으므로 Windows 10과 Windows 11이 모두 보고합니다
Windows NT 10.0. 문자열은 이들을 전혀 구분할 수 없습니다.
파서는 이런 함정에 대해 알고 있는 작은 정돈된 규칙 더미입니다. 그게 정말 전부이지만,정확하게 순서를 잡는 것이 전체 게임입니다.
Toolz 사용자 에이전트 파서는 어떻게 작동합니까?
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 10 파서 순서가 위의 트랩을 인코딩하는 수표의 시퀀스를 실행합니다. 그것은 다른 browser's 토큰을 먼저 임베드 브라우저를 찾습니다. 크롬 전에 가장자리,크롬 전에 오페라,삼성 인터넷과 UC 브라우저 크롬 전에,그래서 빌린 Chrome 토큰은 결코 우연히 승리하지 못합니다. 그것의 Safari 를 읽습니다 Version/ 그것의 보다는 토큰 Safari/ 빌드 토큰. iOS 변형을 인식합니다 CriOS 그리고 FxiOS 엔진을 WebKit으로 올바르게 보고하면서 각각 Chrome 및 Firefox로 사용됩니다.
운영 체제의 경우 Windows NT 커널 번호를 마케팅 이름에 매핑합니다 Windows NT 6.1 윈도우 7 이 되고 Windows NT 10.0 는 Windows 10 또는 11 이 되며 문자열이 진정으로 구별할 수 없기 때문에 쌍으로 정직하게 명시됩니다. 헤더가 다음과 같은 밑줄로 쓰는 iOS 및 macOS 버전의 점선 형식을 복원합니다 17_5그리고 Android, Chrome OS, Linux를 인식합니다.
장치의 경우 요청을 데스크톱, 모바일, 태블릿 또는 봇으로 분류합니다. 태블릿 규칙은 까다로운 것입니다: iPad는 태블릿, Android 장치가 없는 장치입니다 Mobile 토큰은 태블릿이고 일치하는 모든 것입니다 Mobile, iPhone, 또는 Windows Phone 는 전화기입니다. 문자열이 Android 빌드 문자열이나 Apple 제품 이름과 같은 장치 모델을 노출하는 경우 파서가 이를 표면화합니다.
또한 봇에 플래그를 지정합니다. 액세스 로그를 읽을 때 가장 유용한 질문은 트래픽이 얼마나 자동화되는지이기 때문에 이것이 제가 가장 많이 도달하는 필드입니다. 파서는 검색 크롤러,소셜 미리보기 가져오기 및 명령줄 클라이언트를 포괄하는 광범위한 서명 세트와 일치합니다.
사용자 에이전트는 무엇을 알려줄 수 있고, 무엇을 말해줄 수 없습니까?
문자열을 사실로 취급하면 잘못된 결정이 내려지기 때문에 한계에 대해 정확하게 설명할 가치가 있습니다.
| 질문 | UA 가 대답할 수 있나요? | 노트 |
|---|---|---|
| 어떤 브라우저 가족 | 보통 그렇습니다 | 정확한 탐지 순서로 |
| 정확한 브라우저 버전 | 보통 그렇습니다 | 점점 냉동되거나 감소됩니다 |
| 운영 체제 이름 | 보통 그렇습니다 | 윈도우 10 대 11 은 불가능하다 |
| 장치 유형 | 대충 | 휴리스틱, 보장되지 않음 |
| 정확한 장치 모델 | 가끔 | 문자열에 포함된 경우에만 |
| 클라이언트가 정품인지 여부 | 아니요 | 사소하게 스푸핑 가능합니다 |
| 화면 크기 또는 기능 | 아니요 | 대신 기능 감지를 사용하십시오 |
마지막 두 행이 가장 중요합니다. User-Agent 는 자체 보고되며 한 줄의 코드에서 변경되거나 HTTP 클라이언트에서 설정되거나 개인 정보 보호를 위해 브라우저에서 동결될 수 있습니다. 스크레이퍼는 Windows 에서 자신을 Chrome 으로 발표할 수 있으며 문자열에는 모순되는 내용이 없습니다. 따라서 구문 분석된 결과는 클라이언트가 주장하는 내용을 알려주며 이는 통계 및 디버깅에 유용하지만 아무 것도 증명할 수 없습니다. 브라우저가 실제로 무엇을 할 수 있는지 알아야 할 때 이름에서 기능을 추론하는 대신 JavaScript 에서 기능을 감지합니다. 이는 탄력적인 프런트 엔드 코드를 작성하는 것과 동일한 원칙입니다 웹 개발자 툴킷 검거는 반복적으로 돌아옵니다.
User-Agent 문자열이 사라지고 있습니까?
정확히는 아니지만,의도적으로 축소되고 있습니다. Chromium 브라우저는 몇 년 동안 레거시 문자열을 동결하고 다듬어 왔으며,특히 사소한 버전 번호와 일부 플랫폼 세부 사항을 노출하는 세부 수준을 제한했습니다. 교체는 사용자 에이전트 클라이언트 힌트서버가 필요한 클라이언트 정보를 정확하게 요청하는 메커니즘입니다 Sec-CH-UA 헤더 요청 및 navigator.userAgentData 자바 스크립트 API, 오히려 하나의 긴 문자열을 수신하는 것보다 그것은 구문 분석해야 클라이언트 힌트는 또한 윈도우 10 대 11 구별이 마침내 사용할 수있게되는 곳, 통해 Sec-CH-UA-Platform-Version.
향후 몇 년간의 실질적인 결과는 둘 다 존재한다는 것입니다. 클래식 User-Agent 헤더는 여전히 모든 브라우저와 브라우저가 아닌 모든 클라이언트의 모든 요청에 제공되며 많은 툴링,분석 및 서버 측 논리가 여전히 읽습니다. 따라서 문자열을 구문 분석하는 것은 클라이언트를 식별하는 가장 이식 가능한 방법으로 남아 있습니다. 심지어 더 풍부한 데이터가 클라이언트 힌트로 이동하더라도 새로운 것을 구축하고 플랫폼 버전을 정확하게 원한다면 클라이언트 힌트를 읽으십시오; 기존 로그를 분석하거나 가장 광범위한 클라이언트를 지원하는 경우 문자열을 구문 분석합니다.
파서는 어떻게 사용하나요?
흐름은 의도적으로 간단합니다. User-Agent 문자열을 상자에 붙여 넣거나 내장 샘플 중 하나를 클릭하여 대표적인 데스크톱,모바일 또는 봇 문자열을 확인합니다. 직접 가져오려면 브라우저 콘솔을 열고 입력하십시오 navigator.userAgent그리고 결과를 붙여넣습니다. 입력할 때 브라우저,엔진, 운영 체제,장치 유형,CPU 아키텍처,봇 플래그 업데이트가 실시간으로 이루어지며 누를 버튼이 없습니다. 다른 곳에서 결과를 원할 때는 스프레드시트나 버그 보고서에 깔끔하게 붙여넣는 탭으로 구분된 테이블로 복사합니다.
모든 것이 브라우저에서 실행되기 때문에 원시 액세스 로그 라인이나 실제 방문자 문자열을 시스템에서 벗어나지 않고 붙여넣을 수 있습니다. 해당 클라이언트 측 모델은 의도적이며 사이트의 모든 도구 뒤에 있는 것과 동일합니다 데이터 개인 정보 보호 온라인 도구 안내. 자격 증명의 경우 요청과 함께 디버깅하고 있습니다 기본 인증 생성기 그리고 the JWT 디코더 동일한 업로드 금지 접근 방식을 따르십시오.
파서가 다른 웹 도구와 맞는 위치
사용자 에이전트 파서는 사이트의 작은 요청 및 응답 도구 클러스터에 있습니다. 도메인으로의 트래픽을 검사할 때, the 도메인 검색 도구는 누가 소유하고 운영하는지 답변합니다. 요청이 검사해야 하는 베어러 토큰을 운반하는 경우, the JWT 디코더 그것에서 주장을 읽습니다. 처음에 인증된 요청을 구성할 때, 기본 인증 생성기 를 구축합니다 Authorization 헤더. 그리고 자신의 사용자 에이전트 아래에서 페이지를 읽는 크롤러에게 페이지가 어떻게 표시되는지 작업할 때 메타 태그 생성기 그들이 소비하는 태그를 형성합니다.
이들의 개인 세트를 조립하는 모든 사람에게 개발자 생산성 도구 가이드는 사이트의 브라우저 기반 유틸리티가 근무일에 어떻게 적용되는지 다룹니다. 이들을 함께 유지하는 요점은 HTTP 상호 작용을 디버깅하는 데 이러한 질문 중 하나만 포함되는 경우가 거의 없다는 것입니다.
실용적인 워크플로: 트래픽 로그 읽기
이 길에서 저를 시작하게 한 과업으로 이 구체를 만들어 보겠습니다. 여러분은 여러분의 접근 로그의 한 조각을 내보냈고 여러분은 그것을 이해하기를 원합니다. 순진한 접근법은 사용자-에이전트 열을 눈알로 보는 것입니다. 이 열은 정확히 함정이 물린 곳과 같이 공손하게 자신을 식별하는 크롤러입니다 Googlebot 쉽지만 일반 Chrome 빌드로 자신을 알리는 헤드리스 스크레이퍼는 다른 신호를 확인할 때까지 실제 방문자와 동일하게 보입니다.
파서는 두 가지 방법으로 도움이됩니다. 첫째,봇 플래그는 정직한 크롤러와 일반적인 자동화 클라이언트를 즉시 잡기 때문에 한 번의 패스로 명백한 기계 트래픽과 사람의 트래픽을 분리 할 수 있습니다. 둘째,나머지 트래픽의 올바른 브라우저 및 OS 분석은 잠재 고객에 대한 실제적인 것을 알려줍니다: 모바일이 왜곡되는지 여부,어떤 운영 체제가 지배적 인지,오래된 브라우저가 여전히 테스트하기에 충분한지 여부. WP Adminify 작업에서 그 고장은 테스트를 위해 우선 순위를 매긴 브라우저를 변경하고 유기적 트래픽처럼 보이는 덩어리가 리더가 아닌 미리보기 및 모니터링 봇임을 확인했습니다. 문자열을 구문 분석하면 소음의 벽이 결정으로 바뀌었습니다.
지켜야 할 한 가지 규율은 한계 섹션의 것입니다: 구문 분석 된 결과는 증거가 아닌 주장입니다. 결정된 스크레이퍼는 설득력있는 문자열을 위조 할 것이며,어떤 파서도 User-Agent 만으로 그것을 잡을 수 없습니다. 위험이 높을 때 요청 패턴,속도 및 기타 신호와 구문 분석을 결합하십시오. 그러나 일상적인 통계 및 디버깅의 경우 올바른 구문 분석이 정확히 필요한 것이며 손으로 수행하는 것은 실수입니다.
렌더링 엔진과 CPU 필드는 나에게 무엇을 말해주는가?
구문 분석된 필드 중 두 개는 브라우저와 OS 보다 덜 주목을 받지만 둘 다 유용합니다. 렌더링 엔진은 HTML 과 CSS 를 실제로 픽셀로 바꾸는 구성 요소이며 브라우저 이름보다 페이지가 어떻게 동작하는지 더 잘 예측할 수 있습니다. Chrome,Edge, Opera,Brave, Samsung Internet 및 대부분의 다른 사람들이 Blink 엔진을 공유하므로 하나에 나타나는 렌더링 버그가 일반적으로 모두 나타납니다; Firefox 는 Gecko 를 사용합니다; Safari 는 iOS 의 모든 브라우저와 함께 WebKit 레이아웃 버그를 분류할 때 브라우저 이름이 아닌 엔진별로 트래픽을 그룹화하면 테스트해야 하는 진정으로 구별되는 렌더링 경로가 몇 개나 되는지 알려줍니다. 이는 종종 세 개에 불과합니다.
파서는 브라우저 레이블이 아닌 플랫폼 토큰에서 엔진을 파생하므로 둘 다 동일한 AppleWebKit 토큰에서 파생되었음에도 불구하고 Chromium 브라우저용 Blink와 Safari용 WebKit을 보고할 수 있습니다. 또한 이전 엔진인 Internet Explorer용 Trident와 레거시 Edge용 EdgeHTML도 포착합니다. 이 엔진은 여전히 엔터프라이즈 로그에 표시됩니다.
CPU 아키텍처 필드는 플랫폼 토큰을 읽습니다 x86_64, Win64, arm64그리고 그들의 친척, 클라이언트가 64 비트, 32 비트 또는 ARM 기계 인지 보고. 플랫폼별 다운로드를 언제 제공 하는지 확인 하 고 방문자가 실행할 수 있는 빌드를 알아야 하는 필드 이며, audience's 하드웨어가 얼마나 현대적인지 보여주는 조용한 신호입니다.
자주 묻는 질문
User-Agent 문자열이란 무엇입니까? User-Agent 문자열은 브라우저나 클라이언트가 각 요청과 함께 보내는 User-Agent HTTP 헤더의 값입니다. 이는 RFC 9110 에 정의된 브라우저,렌더링 엔진,운영 체제,그리고 종종 장치의 이름을 지정하는 제품 토큰의 목록을 서버가 읽어 해당 서버에 연결하는 소프트웨어를 식별합니다.
내 자신의 User-Agent 를 어떻게 찾을 수 있습니까? 브라우저를 열고's 개발자 콘솔을 열고 navigator.userAgent 를 입력한 다음 Enter 키를 누릅니다. 인쇄하는 문자열은 브라우저가 서버에 보내는 것과 정확히 같습니다. 사용자 에이전트 파서에 붙여넣으면 디코딩하는 브라우저,운영 체제 및 장치를 볼 수 있습니다.
Chrome's User-Agent 에 Safari 라는 단어가 포함되는 이유는 무엇입니까? 이전 버전과의 호환성을 위해. Chrome 은 Apple's WebKit 에서 엔진을 포크했고,초기 서버는 최신 페이지를 제공하기 전에 Safari 토큰을 확인했기 때문에 Chrome 은 다운그레이드되지 않도록 보관했습니다. 동일한 기록으로 인해 거의 모든 브라우저가 여전히 Mozilla/5,0 으로 문자열을 시작합니다.
사용자 에이전트가 Windows 11에서 Windows 10을 구분할 수 있나요? 아니요. Microsoft 가 Windows 11 용 NT 커널 토큰을 증가시키지 않았기 때문에 둘 다 Windows NT 10,0 을보고하므로 문자열만으로는 두 가지를 구별 할 수 없습니다. 이들을 구별하는 현대적인 방법은 User-Agent Client Hints,특히 Sec-CH-UA-Platform-Version 헤더입니다.
사용자 에이전트가 장치를 식별하는 데 신뢰할 수 있습니까? 증거가 아닌 유용한 힌트입니다. 사용자 에이전트는 한 줄의 코드에서 변경되거나,모든 HTTP 클라이언트에 의해 설정되거나,스크레이퍼에 의해 스푸핑되거나,개인정보 보호를 위해 브라우저에 의해 동결될 수 있습니다. 구문 분석된 결과를 클라이언트가 주장하는 대로 처리하고,정확성이 중요할 때 다른 신호와 결합합니다.
파서는 어떻게 봇과 크롤러를 감지합니까? Googlebot 및 Bingbot 과 같은 검색 크롤러,소셜 미리보기 가져오기 도구 및 curl,wget 및 headless Chrome 과 같은 자동화 클라이언트를 포함하여 알려진 서명의 광범위한 목록에 문자열을 일치시킵니다. 모든 일치 항목에서는 봇 플래그를 설정하고 장치를 크롤러로 분류합니다.
여기에 생산 로그 User-Agents 를 붙여넣는 것이 안전한가요? 예. 모든 구문 분석은 JavaScript 를 사용하여 브라우저에서 발생하며 문자열은 어떤 서버로도 전송되지 않습니다. 원시 액세스 로그 줄이나 실제 방문자 User-Agents 가 장치를 떠나지 않고 붙여 넣을 수 있습니다.
User-Agent 문자열이 더 이상 사용되지 않습니까? 헤더가 제거되지 않고 고정되고 축소됩니다. Chromium 브라우저는 이제 레거시 문자열의 세부 정보를 캡핑하고 대신 User-Agent Client Hints 를 통해 더 풍부한 데이터를 노출합니다. 클래식 문자열은 여전히 모든 요청에 제공되므로 구문 분석은 클라이언트 세부 정보를 읽는 가장 이식 가능한 방법으로 남아 있습니다.
